On Wed, Mar 5, 2025, at 11:50 AM, Edmond Dantes wrote:
>> You might want to look to parallel extension as it's already dealing
>> with that and mostly works - of course combination with coroutines will
>> certainly complicate it but the point is that memory is not shared.
>
> Do you mean this extension: https://www.php.net/manual/en/book.parallel.php?
>
> Yes, I studied it before starting the development of True Async. My
> very first goal was to enable, if not coroutine execution across
> threads, then at least interaction, because the same thing is already
> possible with Swoole.
*snip*
> Such a language update would create an "extension vacuum." When a new
> version is released, many extensions will become unavailable due to the
> need to adapt to the new multitasking model.
It would necessitate a major version release, certainly.
>> I didn't really mean to introduce it as part of this RFC.
>> What I meant is to design the API so there is still possibility to add it in
>> the future without risking various race condition in the code.
>> It means primarily to put certain restrictions that will prevent it like
>> limited access to global and passing anything by
>> reference (including objects) to the running tasks.
>
> Primitives like *Context* are unlikely to be the main issue for
> multitasking. The main problem will be the code that has been developed
> for many years with single-threaded execution in mind. This is another
> factor that raises doubts about the rationale for introducing real
> multitasking in PHP.
I think the point is more that the concurrency primitives that are introduced
(async block, async() function, whatever it is) should be designed in such a
way that PHP could introduce multiple parallel threads in the future to run
multiple async blocks simultaneously... without any impact on the *user* code.
To reuse my earlier example:
function parallel_map(iterable $it, Closure $fn) {
$result = [];
async $ctx {
foreach ($it as $k => $v) {
$result[$k] = $ctx->run($fn($v));
}
}
return $result;
}
Whether each run() invocation is handled by one thread switching between them
or 3 threads switching between them is not something the above code should care
about. Which means designing that API in such a way that I... don't need to
care. Which probably means something like "no inter-fiber communication other
than channels", as in Go. And thinking through what it means for the context
object if it does have some kind of global property bag. (This is one reason I
don't want one.) And it means there's no way to control threads directly from
user-space. You just get async blocks, and that's it. This is an area that Go
got pretty solidly right, and is worth emulating.
The implications on C code of adding true-thread support in the future is a
separate question; the async API should be built such that it *can* be a
separate future question.
--Larry Garfield
