Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122074
MIME-Version: 1.0
References: <CADU7aovcatZ++PSg0Pt0-kXJH9Oe09N0jy5uXEoBYoRv6GeUwQ@mail.gmail.com>
 <5060b986-2e5a-46e4-9c83-763e5b155e83@gmail.com> <CADU7aoutXwr2puZnzMJk+iNfxf-xE-2DKviSTHLK+TR3xpzsQA@mail.gmail.com>
 <6f7815b9-80cc-4e08-819a-49dca090116f@gmail.com> <CAPzBOBMzL78Fxb+sDTyfCoR0psKzkp8o50+RwQ2Y3Sz+K+7jUQ@mail.gmail.com>
 <7F63D301-1A46-49AA-9140-F64543E902C5@gmail.com> <8fb6672c-06e9-4f74-b2f2-cd1a265c75a5@app.fastmail.com>
In-Reply-To: <8fb6672c-06e9-4f74-b2f2-cd1a265c75a5@app.fastmail.com>
Date: Sat, 30 Dec 2023 21:09:29 +0100
Message-ID: <CABdc3WrN5xBwk+nbr=eLOV9aMcqYyxMVLOeKXhBUP2C14v_g4g@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000a62c70060dbfba38"
Subject: Re: [PHP-DEV] RFC proposal: worker mode primitives for SAPIs
From: michal.brzuchalski@gmail.com (=?UTF-8?Q?Micha=C5=82_Marcin_Brzuchalski?=)

--000000000000a62c70060dbfba38
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Larry,

sob., 30 gru 2023 o 20:49 Larry Garfield <larry@garfieldtech.com>
napisa=C5=82(a):

> On Sat, Dec 30, 2023, at 4:53 AM, Rowan Tommins wrote:
> > On 30 December 2023 09:59:07 GMT, Robert Landers
> > <landers.robert@gmail.com> wrote:
> >>For this to happen in PHP Core, there would need to be request objects
> >>instead of a global state.
> >
> > Again, the representation as objects isn't a key requirement. Python's
> > WSGI spec simply has a dictionary (read: associative array) of the
> > environment based on CGI. The application might well turn that into a
> > more powerful object, but standardisation of such wasn't considered a
> > pre-requisite, and would actually have hampered ASGI, where not all
> > events represent an HTTP request.
> >
> > The key requirement is that you have some way of passing the current
> > request and response around as scoped variables, not global state.
> > That's essential for any kind of concurrent run-time (async,
> > thread-aware, etc).
> >
> > An event / subscriber model fits well with that: the local scope for
> > each request is set up by an invocation of the callback with defined
> > parameters and return value.
> >
> > Funnily enough, the example of a worker script for FrankenPHP does both
> > things: it sends each request to the same application "handle"
> > callback, passing in the super-global arrays as parameters to be used
> > as non-global state. https://frankenphp.dev/docs/worker/#custom-apps So
> > really all I'm arguing is that a few more lines of that PHP example be
> > moved into the C implementation, so that the user only needs to provide
> > that inner callable, not the outer while loop.
>
> So you're suggesting something like:
>
> $app->initializeStuffHowever();
> set_event_handler(Closure $handler);
> // Script blocks here until a sigkill is received, or something.
>
> I think there's an important distinction that is getting missed in the
> above discussion, beyond the push-vs-pull question.  FrankenPHP, as I
> understand it, pre-boots multiple worker processes, keeps them in memory,
> and then handles each request in its own process.  Swoole,
> Amp/React/Revolt, and friends have only a single process running at all,
> and make use of async to simulate multiple simultaneous requests, a la
> NodeJs.  That means mutable global variables in the FrankenPHP model stil=
l
> won't leak between parallel requests, whereas they absolutely would/do in=
 a
> Swole/Revolt world.
>
> I'm not going to call one of those better or worse (I don't have enough
> experience with either to say), but they are different beasts for which
> first class support would be different SAPIs either way.  They're not
> mutually exclusive thanks to Fibers (which mean you don't need the entire
> call stack to be async), but you would want to pick one or the other as
> primary runner mode of an application.  Let's keep that in mind when maki=
ng
> comparisons.
>
> The Franken-model is closer to how PHP-FPM works today, which means that
> is easier to port existing code to, especially existing code that has lot=
s
> of globals or hidden globals.  (Eg, Laravel.)  That may or may not make i=
t
> the better model overall, I don't know, but it's the more-similar model.
>
> All that said, the idea of allowing a "persistent HTTP handler process"
> SAPI, "persistent Queue handler process" SAPI, and "persistent cron handl=
er
> process" SAPI (or whatever combination of persistent processes) to all ru=
n
> side by side with the same code base but different entry point scripts
> is...  Hot.  If we can do something that would enable that kind of runtim=
e
> model, I am very much here for that.
>

What you wrote sounds like some good points (as usual).
I'm not an expert (yet!) but was playing around with some callable trying
to mimic ASGI
https://github.com/brzuchal/asgi-playground/blob/main/app.php#L26-L37

What I think currently (maybe too hurry, but...) is that this kind of
approach is flexible enough to handle in easy way many SAPIs which identify
to app their capabilities,
and the app decides how and what can handle `$scope['type']` in the example
code.

I know there is a Runtime library, that tries to integrate
Symfony/Laaravel to many SAPIs, but as far as I understood the discussion
went to figure out if there is some kind of standard approach that could be
shaped under the PHP umbrella.

Maybe this is just a temporary fascination about ASGI solution, could be.
If this is not in the scope of interest of anyone then forgive me, I won't
bother anymore.

Cheers,
--
Micha=C5=82 Marcin Brzuchalski

--000000000000a62c70060dbfba38--