Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126584
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Wed, 05 Mar 2025 12:38:24 -0600
To: "php internals" <internals@lists.php.net>
Message-ID: <def24341-f2c7-4be7-8000-a11b812515ee@app.fastmail.com>
In-Reply-To: 
 <CAMW7n8BDFYJ=U9=LbL83fD6k9gPM2PThzfB0BhDZLm2c7ovocA@mail.gmail.com>
References: 
 <CAMW7n8AJckEDzhGv9BdjNhq8zAdCqb4HsVr56vGi+izw50X6Dg@mail.gmail.com>
 <CAEKnhAHv_3bR+Fnmg=mGXuDJhpmAjTMwj0VhAt8TOcjiD+YJzw@mail.gmail.com>
 <CAMW7n8DHFb6innyn6VigDtQGb9EYu9-H_v5m_XGJWHEQG+q2OA@mail.gmail.com>
 <CAEKnhAGc-hOPkEfiBouA+XD0A1oEjt1jtg_u=uZohbbDYg=7Pg@mail.gmail.com>
 <CAMW7n8BDFYJ=U9=LbL83fD6k9gPM2PThzfB0BhDZLm2c7ovocA@mail.gmail.com>
Subject: Re: [PHP-DEV] PHP True Async RFC
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
From: larry@garfieldtech.com ("Larry Garfield")

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