Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122120
MIME-Version: 1.0
References: <CADU7aovcatZ++PSg0Pt0-kXJH9Oe09N0jy5uXEoBYoRv6GeUwQ@mail.gmail.com>
 <3828a559-5dae-44d1-96ce-dff1a8b07c18@gmail.com> <CAPzBOBOx25-muH8BuMFJAHJp=L8wT_M-W8G-kk6fsPb9Lv_T0A@mail.gmail.com>
 <DABECB67-A138-4184-8E24-8CC9ED4802C4@gmail.com> <CAPzBOBM0tYMfi5T9K4J3i-1yBg_n=ZyeziGoQBXTvGjXZEOsgg@mail.gmail.com>
 <99C434B3-3953-4E90-8DEA-94237332219D@gmail.com>
In-Reply-To: <99C434B3-3953-4E90-8DEA-94237332219D@gmail.com>
Date: Fri, 5 Jan 2024 13:18:51 +0100
Message-ID: <CAPzBOBPRGBOp36sgJf0BoTaZjbi3HT7TW-9eZpS7h9w+OORfyA@mail.gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Cc: 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 11:59=E2=80=AFAM Rowan Tommins <rowan.collins@gmail.=
com> wrote:
>
> On 5 January 2024 09:02:05 GMT, Robert Landers <landers.robert@gmail.com>=
 wrote:
> > I don't think they are fundamentally incompatible. If we look at
> >FrankenPHP's implementation, you pass a callback that gets called when
> >there is a request.
>
> No, you pass a callback which is called exactly once, for the next reques=
t. You have to implement your own loop if you want to handle multiple reque=
sts, which obviously isn't how it would work with an async event loop.
>
> That was one of my suggested changes: move the loop into C, so that the A=
PI was "callback called for each request". This actually *adds* flexibility=
 on the server end, to decide how often to call that callback, do so asynch=
ronously, etc.

I think the goal here is to provide the basic building block: a
function that takes a callable that, when called, blocks the script.
Even when you have an event loop, there is some point when you call
something and enter an infinite loop (the event loop), and no more of
that file will be called ($app->start() or whatever). This is _that
function_ for all intents and purposes. You can implement your own
event-loop using do/while (such as in FrankenPHP), or a SAPI can call
it in a loop for you. The bedrock is in core PHP, providing a
standardized way of setting this up ... obviously, there are also
SAPIs out there doing their own thing, and there always will be.

> > Globals is how this works (atm)
>
> It's how it works for native SAPIs. It's not, as far as I know, how any w=
orker system other than FrankenPHP has implemented its API. Every other imp=
lementation I've seen, whether async or not, passes in some form of request=
 data to the callback, with the exception of RoadRunner, which gives the da=
ta as a return value from a "get next request" function.

Nearly every library in existence knows how to use these globals
(including 30 years old legacy code). There are also the unwieldy PSR
request/response containers for which there are dozens (if not
hundreds) of implementations. It would be fantastic if there were
already an extension-based implementation that could be adopted into
php-src; though I feel like that is a separate conversation.

> So, the second suggested change is to standardise on the most common patt=
ern of passing parameters to a callback, rather than the unusual one of pop=
ulating and clearing superglobals. As a bonus, this pattern works with both=
 non-async and async workers.
>
>
> > changing the signature of the callback is generally backwards compatibl=
e
>
> This is true in the narrow sense that it won't cause any fatal errors. Bu=
t if you write your application assuming that it will run in an environment=
 where globals are populated for you, it will not run in an environment whi=
ch no longer populates those globals.

This is easy to handle from C. If the callback takes an argument,
don't fill in the super-globals. It allows legacy apps to be slowly
"upgraded" while allowing newer apps to take full advantage of a SAPI.
That's how I would implement it, anyway. There is also something to be
said to go "all the way" and just abandoning legacy apps, but that
doesn't feel like something PHP would do.

> >Changing the underlying implementation in php-src when there are
> >native fibers/event loops probably won't even change anything (since
> >that was exactly how they were designed).
>
> Sounds great! So we don't need to wait to put that implementation in plac=
e then.
>
>
>
> >But holding up the entire conversation ...
>
> There is no reason whatsoever to hold anything up. The suggestion is not =
"don't implement any worker API until we have an async implementation", it'=
s "a worker API sounds great, let's implement one that looks like this".
>
> Yes, it might take slightly longer to define some new array structures, b=
ut we're talking about a few hours work to give us a much more flexible sys=
tem, not weeks of complex engineering.
>
> If the proposal is "copy some code from FrankenPHP into php-src, which no=
body else will want to use", it's pointless; if it's "standardise an API wi=
th some enabling code", then *of course* we want to spend a bit of time des=
igning that API.

That's fair. I was taking this push-back from you and others as, "No,
we don't want this unless we can have all these other things," so
thank you for clarifying that. I can largely agree -- I use amphp +
fibers extensively in another project, so seeing more love for
concurrent servers would be nice. Maybe I saw it that way because I
have a fairly deep understanding of the shortcomings with
fibers/async-php and see the amount of work required to support what
you are proposing. However, if we go into the design with the
concurrent server story in mind, I think we can create something much
better than what is available from FrankenPHP.

> Regards,
>
> --
> Rowan Tommins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>