Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122075
Date: Sun, 31 Dec 2023 01:20:01 +0000
To: php internals <internals@lists.php.net>
User-Agent: K-9 Mail for Android
In-Reply-To: <8fb6672c-06e9-4f74-b2f2-cd1a265c75a5@app.fastmail.com>
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>
Message-ID: <96C28696-7C58-4018-84EB-69CF4189649B@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 30 December 2023 19:48:39 GMT, Larry Garfield <larry@garfieldtech=2Ecom>=
 wrote:
>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 lots =
of globals or hidden globals=2E  (Eg, Laravel=2E)  That may or may not make=
 it the better model overall, I don't know, but it's the more-similar model=
=2E

That's why I said earlier that it provides better backwards compatibility =
- existing code which directly uses PHP's current global state can more eas=
ily be run in a worker which populates that global state=2E

However, the benefit is marginal, for two reasons=2E Firstly, because in p=
ractice a lot of applications avoid touching the global state outside of so=
me request bootstrapping code anyway=2E The FrankenPHP example code and Lar=
avel Octane both demonstrate this=2E

Secondly, because in an environment that handles a single request at a tim=
e, the reverse is also possible: if the server passes request information d=
irectly to a callback, that callback can populate the superglobals as appro=
priate=2E The only caveat I can think of is input streams, since userland c=
ode can't reset and populate php://input, or repoint STDOUT=2E

On the other hand, as soon as you have any form of concurrency, the two mo=
dels are not interchangeable - it would make no sense for an asynchronous c=
allback to read from or write to global state=2E

And that's what I meant about FrankenPHP's API having poor forward compati=
bility - if you standardise on an API that populates global state, you clos=
e off any possibility of using that API in a concurrent environment=2E If y=
ou instead standardise on callbacks which hold request and response informa=
tion in their own scope, you don't close anything off=2E

If anything, calling this "forwards compatibility" is overly generous: the=
 OP gave Swoole as an example of an existing worker environment, but I can'=
t see any way that Swoole could implement an API that communicated request =
and response information via global state=2E

Regards,

--=20
Rowan Tommins
[IMSoP]