ext-parallel crashes in worker mode

[henderkes]

What happened?

creating new threads from worker mode crashes the currently running worker thread.
repro:

<?php

$handler = static function () {
    return frankenphp_handle_request(static function () {
        $runtime = new parallel\Runtime();
        $future = $runtime->run(function () {
            return 'hello from thread';
        });

        echo $future->value();
    });
};

while ($handler()); // first hit -> segfault

Build Type

Docker (Debian Trixie)

Worker Mode

Yes

Operating System

GNU/Linux

CPU Architecture

x86_64

PHP configuration

phpinfo() output

-

Relevant log output

Relevant log output

-

[henderkes]

Okay, not quite as easy to solve as I'd hoped. When any function that reaches out into our extension is called, i.e. to read POST data, SESSION, cookies or anything, it uses the thread_index, which doesn't actually exist in threads not spawned by frankenphp.

What's our desired behaviour here? Mutex around the "parent" threads things? Just noop?

[AlliBalliBaba]

I think it should be fine to read from the same globals. Haven't tried this yet, is the thread maybe trying to flush the response?

[henderkes]

I think it should be fine to read from the same globals. Haven't tried this yet, is the thread maybe trying to flush the response?

I'm not sure about it. Perhaps, but I think it would actually require use to overwrite the parallel\run and Runtime::run functions, otherwise we have no idea who spawned the thread.

[henderkes]

Oh, the crashing one is frankenphp_read_cookies upon sapi startup, by the way. It#s accessing thread id 0 but it doesn't exist.

I'm not sure why it works in regular mode.

[AlliBalliBaba]

Probably in regular mode, the thread with ID 0 is the current thread. In worker mode, it's a regular thread, that currently does not have a context.

The threads started from the parallel extension automatically get 0 assigned. We could make the 0-thread a special thread that always has a fake context.

Not sure why these threads are accessing cookies in the first place though, seems inefficient.

[dunglas]

Maybe could we deep clone the parent context to ensure that features such as structured logging continue working?

[henderkes]

Little update: regular mode crashes too as soon as more than 1 request spawns parallel workers. Same thread index 0 on go_read_cookies.

Maybe could we deep clone the parent context to ensure that features such as structured logging continue working?

Our $_SERVER arrays probably yes, but I'll pass on implementing this one myself, just because I don't have a clear vision for what the right approach is. Another possibility would be just safety checking and returning NULL since technically all these things shouldn't even exist in request-less threads. That should be ok for everything but frankenphp_log.