Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122114
MIME-Version: 1.0
References: <CADU7aovcatZ++PSg0Pt0-kXJH9Oe09N0jy5uXEoBYoRv6GeUwQ@mail.gmail.com>
 <3828a559-5dae-44d1-96ce-dff1a8b07c18@gmail.com>
In-Reply-To: <3828a559-5dae-44d1-96ce-dff1a8b07c18@gmail.com>
Date: Fri, 5 Jan 2024 07:55:34 +0100
Message-ID: <CAPzBOBOx25-muH8BuMFJAHJp=L8wT_M-W8G-kk6fsPb9Lv_T0A@mail.gmail.com>
To: Daniil Gentili <daniil.gentili@gmail.com>
Cc: =?UTF-8?Q?K=C3=A9vin_Dunglas?= <kevin@dunglas.fr>, internals@lists.php.net
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] RFC proposal: worker mode primitives for SAPIs
From: landers.robert@gmail.com (Robert Landers)

On Fri, Jan 5, 2024 at 2:56=E2=80=AFAM Daniil Gentili <daniil.gentili@gmail=
.com> wrote:
>
> Hi,
>
> I've been lurking around in the discussion for a while, and I'd like to c=
hime in now since the main, glaring issue with this proposal has only been =
explicitly mentioned by Rowan Tomminis, with that subthread quickly degener=
ating with misguided replies.
>
> PHP as a language absolutely needs a persistent worker mode like in all o=
ther backend languages, which will greatly improve performance by avoiding =
all overhead related to request initialization.
>
> However, the current proposal of adding support for worker mode SAPIs bas=
ed on the usual PHP superglobals is fundamentally incompatible with concurr=
ency (aka async, aka swoole, amphp, fiber-based concurrent runtimes in gene=
ral), and I believe would steer the PHP ecosystem in the wrong direction.
>
> Rowan already offered a nice example of why earlier in the thread, but as=
 an explanation to those that may not have understood that, so I whipped up=
 a briefer at https://gist.github.com/danog/f0e9103e6a7e1bcec1b92c411a3c460=
7
>
>
>
> So no, unlike what I've read in another message here, "The nodejs curse [=
...] where async and co may actually slow down your whole node." is simply =
false for the majority of modern usecases, because the majority of modern a=
pplications is I/O-intensive, not CPU-intensive.
>
>
> Implementing a worker API the way it is proposed is fundamentally incompa=
tible with userland cooperative schedulers aka event loops like amphp or re=
actphp, and each request would be handled, just like in php-fpm, in a separ=
ate OS thread, not in a much more efficient userland thread.
>
> Cooperative schedulers implemented outside of PHP in the form of an exten=
sion such as swoole would also not be able to easily make use of the initia=
lly proposed API to handle requests in separate coroutines, even if the han=
dle_request function was intercepted by swoole to return control to the swo=
ole event loop (which would already make it superfluous as a PHP API), sinc=
e the proposal involves messing around with the usual superglobals, which a=
s mentioned by Rowan would require manual copying of the superglobals befor=
e using them in a newly spawned swoole coroutine.
>
> I believe that a much, much better way of implementing a worker mode in P=
HP core would be to provide a fiber-aware function/static method returning,=
 upon receiving a request, a class implementing the PSR-7 RequestInterface.
>
> Fiber-aware here means that the function should behave in a way similar t=
o how all native PHP I/O functions should behave in an upcoming Native Even=
t Loop RFC I'm planning to make.
>
> The idea here is to make all I/O related functions, including this new wa=
it_request function, completely async in a manner that is compatible with f=
ibers and pure PHP event loops like amphp.
>
> It would essentially work as follows: an event loop like uv is integrated=
 within PHP itself at least for the native stream wrapper (I.e. all filesys=
tem and network functions, file_get_contents and so on).
> Extensions will be provided an API to interact with the event loop.
>
> I'm currently finalizing the details, and might probably make a first RFC=
 in the coming weeks, suffice to say that everything will work in a manner =
very similar to how async works in both the ext-pq and php-tokio extensions=
, albeit with fiber integration: a separate event loop (let's call it nativ=
e) is started in another OS thread (like with ext-pq or php-tokio, WITHOUT =
the need for ZTS, as no PHP data structures are modified in the native even=
t loop), events are sent via a single descriptor from the native event loop=
 to the userland event loop (I.e. amphp).
>
> If running inside a fiber, tasks are queued to the native event loop and =
the fiber is suspended with a NativeSuspension, then resumed by the userlan=
d event loop.
>
> If not running inside a fiber, tasks are queued to the native event loop =
and control is returned to the userland event loop.
>
> Essentially, my proposal is almost exactly what is already being done in =
https://github.com/danog/php-tokio, but library-agonstic and implemented in=
side of PHP itself, perhaps even using Rust and tokio as well.
>
> I feel that the current direction of the discussion of PHP worker modes i=
s wrong, as it is mostly ignoring the presence of a perfectly usable concur=
rency API in PHP (fibers): this has potential to cause a big split in the P=
HP ecosystem, unless PHP finally fully embraces concurrency and async with =
a native event loop proposal, like the one I intend to present soon.
>
> I hope that further discussion of a worker mode continues with an eye to =
the future with native concurrency :)
>
> Regards,
> Daniil Gentili.
>
> P. S. Just in case to avoid confusion for some, frankenphp does NOT add n=
ative concurrency to php using goroutines, as control to the go event loop =
is only returned when calling functions like header or echo which cause a s=
uspension of the goroutine because an I/O operation is made on the go side,=
 but
>
> 1) That's incompatible with fibers, and not just because of the minor go =
compatibility bug which is being fixed, but because the go event loop is no=
t integrated with any php event loop, and thus does not know to return cont=
rol to any eventual php fiber when needed, and will just block all PHP fibe=
rs until that single go I/O operation is done (unlike in php-tokio, where t=
he rust tokio event loop is fully integrated with the php event loop (curre=
ntly just revolt)).
>
> 2) It doesn't even replace the native stream wrapper with go-backed async=
 I/O like swoole does (though both this and php event loop integration like=
 in php-tokio is fully possible in frankenphp with a bit of work, I could a=
ctually lend a hand if needed...)

Hey Daniil,

I already said this, but to reiterate: I, personally, hear what you
are saying and largely agree with you; however, before we can really
have any kind of discussion on concurrent servers, we HAVE to address
the underlying issues that are missing from PHP. In PHP-src, there are
no such things as request objects. There are no such things as event
loops. There are fibers, but absolutely no std-library i/o functions
are using them, making it pointless to build on fibers except when
using user-land libraries that reimplemented everything (like amphp)
in pure PHP or an extension like swoole.

That is the unfortunate point we are at and it doesn't make sense to
address concurrent servers at this moment, or passing request objects.
We have a long way to go before those will be real things that we can
have a proper conversation about in the context of php-src.

Robert Landers
Software Engineer
Utrecht NL