Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122035
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.9.0-alpha0-1364-ga51d5fd3b7-fm-20231219.001-ga51d5fd3
MIME-Version: 1.0
Message-ID: <2272bc41-6ecf-4993-a8eb-f82c9f161b9b@app.fastmail.com>
In-Reply-To: 
 <CADU7aos-nuj9Degv2+DHAvTMsMwKnyVJizMeTrKtzvyiRnabUA@mail.gmail.com>
References: 
 <CADU7aovcatZ++PSg0Pt0-kXJH9Oe09N0jy5uXEoBYoRv6GeUwQ@mail.gmail.com>
 <c100955e-59f6-444d-9b77-c218b7975cd2@app.fastmail.com>
 <CADU7aos-nuj9Degv2+DHAvTMsMwKnyVJizMeTrKtzvyiRnabUA@mail.gmail.com>
Date: Mon, 25 Dec 2023 11:02:58 -0600
To: "php internals" <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: larry@garfieldtech.com ("Larry Garfield")

On Mon, Dec 25, 2023, at 6:34 AM, K=C3=A9vin Dunglas wrote:

> However, I suggest doing this as a second step, because as described i=
n=20
> my first post, it will still be the responsibility of each SAPI to=20
> manage long-running processes and communication with them. This is=20
> simple to do with Go's GoRoutine and Rust's asynchronous runtimes such=20
> as Tokio, it's definitely more difficult in cross-platform C. I sugges=
t=20
> starting by adding the primitives to libphp, then we'll see how to=20
> exploit them (and whether it's worthwhile) in the built-in SAPIs.
> I personally have less interest in working on FPM/CGI/mod_php as the=20
> other possibilities offered by modern SAPIs like FrankenPHP are more=20
> important (better deployment experience as you have a single static=20
> binary or Docker image, Early Hints support, high-quality native HTTP/=
3=20
> server etc), but I'd be happy to help if anyone wants to update these=20
> SAPIs.

>> To what extent would user-space code run this way have to think about=
 concurrency, shared memory, persistent SQL connections, etc?  Does it h=
ave any implications for fiber-using async code?
>
> Regarding concurrency, it doesn't change much (it's similar to existin=
g=20
> SAPI). Regarding memory and SQL connections, extra care is required.=20
> Memory leaks (and other kinds of leaks) should be avoided (or workers=20
> should restart from time to time, which is obviously a poorer=20
> solution). Libraries maintaining SQL connections such as Doctrine or=20
> Eloquent must ensure that the connection isn't active.

Forgive my ignorance, but why no connection?  You mean the pre-worker-st=
art part needs to avoid an SQL connection?  Why is that?  That would be =
something that needs to be super-well documented, and possibly some guar=
ds in place to prevent it, if there's no good way around it.  (This is t=
he sort of detail I'm thinking of, where I just don't know the implicati=
ons but want to think through them as much as possible in advance, so th=
at it can be "safe by design.")

> Fibers work as expected. There is a small limitation when using them=20
> with Go (that is being tracked in the Go runtime,=20
> https://frankenphp.dev/docs/known-issues/#fibers), but it's not relate=
d=20
> to the C code of the worker mode, and this limitation shouldn't exist=20
> for SAPIs not written in Go.
>=20
>> Depending on the details, this could be like fibers but for 3rd party=
 SAPIs (something about 4 people in the world actually care about direct=
ly, everyone else just uses Revolt, Amp, or React, but mostly it doesn't=
 get used), or completely changing the way 90% of the market runs PHP, w=
hich means frameworks will likely adapt to use that model primarily or e=
xclusively (ie, less of a need for a "compile" step as a generated conta=
iner or dispatcher is just held in memory automatically already).  The l=
atter sounds exciting to me, but I'm not sure which is your intent, so I=
 don't know if I'm going too far with it. :-)
>
> My intent is that most SAPIs expose the same (or a very similar=20
> interoperable) worker mode. So (I hope) that most PHP developers will=20
> not have to deal with these primitives directly, but that it will allo=
w=20
> a new generation of super-fast PHP apps to be created. Most frameworks=20
> already support that but require a lot of boilerplate code to support=20
> the different existing engines. Standardizing will likely increase=20
> adoption and will allow collaboration to make the low-level code that =
I=20
> propose to move in libphp as fast, stable, and clean as possible.

Do you have an intent or expectation of a worker-style SAPI being shippe=
d with PHP itself, or for that to remain the domain of third parties?

>> Please advise on what the implications would be for the non-SAPI-deve=
loping PHP devs out there.
>
> None, except that they will be able to use the new handle_request()=20
> function to create a worker script if supported by the SAPI they use.

I mean more what implications would there be on how user-space code is w=
ritten to be worker-SAPI-friendly.  (The SQL connection comment above, f=
or example.)  I have not worked with any of the worker-ish tools so far =
myself, so other than "you'll need an alternate index.php for that", I d=
on't have a good sense of what else I'd want to do differently to play n=
ice with Franken and Friends.

The idea of combining fiber-based code with supported worker-mode runner=
s sounds like a ridiculously cool future for PHP, but I don't know how w=
indy that path is. :-)

--Larry Garfield