Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122119
Date: Fri, 05 Jan 2024 10:59:07 +0000
CC: internals@lists.php.net
User-Agent: K-9 Mail for Android
In-Reply-To: <CAPzBOBM0tYMfi5T9K4J3i-1yBg_n=ZyeziGoQBXTvGjXZEOsgg@mail.gmail.com>
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>
Message-ID: <99C434B3-3953-4E90-8DEA-94237332219D@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] RFC proposal: worker mode primitives for SAPIs
From: rowan.collins@gmail.com (Rowan Tommins)

On 5 January 2024 09:02:05 GMT, Robert Landers <landers=2Erobert@gmail=2Eco=
m> wrote:
> I don't think they are fundamentally incompatible=2E If we look at
>FrankenPHP's implementation, you pass a callback that gets called when
>there is a request=2E

No, you pass a callback which is called exactly once, for the next request=
=2E You have to implement your own loop if you want to handle multiple requ=
ests, which obviously isn't how it would work with an async event loop=2E

That was one of my suggested changes: move the loop into C, so that the AP=
I was "callback called for each request"=2E This actually *adds* flexibilit=
y on the server end, to decide how often to call that callback, do so async=
hronously, etc=2E



> Globals is how this works (atm)

It's how it works for native SAPIs=2E It's not, as far as I know, how any =
worker system other than FrankenPHP has implemented its API=2E Every other =
implementation I've seen, whether async or not, passes in some form of requ=
est data to the callback, with the exception of RoadRunner, which gives the=
 data as a return value from a "get next request" function=2E

So, the second suggested change is to standardise on the most common patte=
rn of passing parameters to a callback, rather than the unusual one of popu=
lating and clearing superglobals=2E As a bonus, this pattern works with bot=
h non-async and async workers=2E


> changing the signature of the callback is generally backwards compatible

This is true in the narrow sense that it won't cause any fatal errors=2E B=
ut if you write your application assuming that it will run in an environmen=
t where globals are populated for you, it will not run in an environment wh=
ich no longer populates those globals=2E



>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)=2E

Sounds great! So we don't need to wait to put that implementation in place=
 then=2E



>But holding up the entire conversation =2E=2E=2E

There is no reason whatsoever to hold anything up=2E 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"=2E

Yes, it might take slightly longer to define some new array structures, bu=
t we're talking about a few hours work to give us a much more flexible syst=
em, not weeks of complex engineering=2E

If the proposal is "copy some code from FrankenPHP into php-src, which nob=
ody else will want to use", it's pointless; if it's "standardise an API wit=
h some enabling code", then *of course* we want to spend a bit of time desi=
gning that API=2E


Regards,

--=20
Rowan Tommins
[IMSoP]