Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122033
MIME-Version: 1.0
References: <CADU7aovcatZ++PSg0Pt0-kXJH9Oe09N0jy5uXEoBYoRv6GeUwQ@mail.gmail.com>
 <c100955e-59f6-444d-9b77-c218b7975cd2@app.fastmail.com>
In-Reply-To: <c100955e-59f6-444d-9b77-c218b7975cd2@app.fastmail.com>
Date: Mon, 25 Dec 2023 13:34:18 +0100
Message-ID: <CADU7aos-nuj9Degv2+DHAvTMsMwKnyVJizMeTrKtzvyiRnabUA@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000008533cb060d54c923"
Subject: Re: [PHP-DEV] RFC proposal: worker mode primitives for SAPIs
From: kevin@dunglas.fr (=?UTF-8?Q?K=C3=A9vin_Dunglas?=)

--0000000000008533cb060d54c923
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, Dec 24, 2023 at 4:21=E2=80=AFPM Larry Garfield <larry@garfieldtech.=
com>
wrote:

In practice, I want to understand the implications for user-space code.
> Does this mean FPM could be configured in a way to execute a file like th=
at
> shown in the docs page above?  Or would it only work with third party SAP=
Is
> like FrankenPHP?


In theory, PHP-FPM and the Apache module could - like all other SAPIs - be
enhanced to add a worker mode operating as described in the FrankenPHP doc
thanks to these new primitives.

However, I suggest doing this as a second step, because as described in my
first post, it will still be the responsibility of each SAPI to manage
long-running processes and communication with them. This is simple to do
with Go's GoRoutine and Rust's asynchronous runtimes such as Tokio, it's
definitely more difficult in cross-platform C. I suggest starting by adding
the primitives to libphp, then we'll see how to 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 other
possibilities offered by modern SAPIs like FrankenPHP are more important
(better deployment experience as you have a single static binary or Docker
image, Early Hints support, high-quality native HTTP/3 server etc), but I'd
be happy to help if anyone wants to update these SAPIs.

I assume the handler function would be differently named.


I suggest naming the function handle_request() or something similar and
using the same name for all SAPIs, so the same worker script will work
everywhere. I'll update FrankenPHP to use the "standard" name.


> Is passing in super-globals the right/best way to handle each request, or
> would it be sensible to have some other abstraction there?  (Whether a
> formal request object a la PSR-7 or something else.)


Passing super-globals is at the same time the most interoperable solution
(it allows using almost all existing PHP libraries in worker mode without
any change to them), and also allows to reuse of the existing C code.
Transforming super-globals in HttpFoundation, PSR-7, or other objects is
straightforward and can entirely be done userland (it's already what the
Symfony Runtime Component and Laravel Octane do), so there is no need to
"bloat" the C code.

Having more high-level data structures to manipulate HTTP messages similar
to HttpFoundation or PSR-7 in the language could be nice (and is in my
opinion needed), but is a separate topic.
If PHP adds a new abstraction for that at some point, it will be easy to
add support for them both in standard and worker mode.


> To what extent would user-space code run this way have to think about
> concurrency, shared memory, persistent SQL connections, etc?  Does it hav=
e
> any implications for fiber-using async code?
>

Regarding concurrency, it doesn't change much (it's similar to existing
SAPI). Regarding memory and SQL connections, extra care is required. Memory
leaks (and other kinds of leaks) should be avoided (or workers should
restart from time to time, which is obviously a poorer solution). Libraries
maintaining SQL connections such as Doctrine or Eloquent must ensure that
the connection isn't active.
The good news is that thanks to RoadRunner, Swoole, Laravel Octane, Symfony
Runtime etc... Most popular libraries are already compatible with
long-running processes, and most issues have been fixed.
Some old apps and libraries will probably never be updatable, but that's
not a big issue because this feature will be entirely opt-in.

Fibers work as expected. There is a small limitation when using them with
Go (that is being tracked in the Go runtime,
https://frankenphp.dev/docs/known-issues/#fibers), but it's not related to
the C code of the worker mode, and this limitation shouldn't exist for
SAPIs not written in Go.


> Depending on the details, this could be like fibers but for 3rd party
> SAPIs (something about 4 people in the world actually care about directly=
,
> 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, which
> means frameworks will likely adapt to use that model primarily or
> exclusively (ie, less of a need for a "compile" step as a generated
> container or dispatcher is just held in memory automatically already).  T=
he
> latter 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
interoperable) worker mode. So (I hope) that most PHP developers will not
have to deal with these primitives directly, but that it will allow a new
generation of super-fast PHP apps to be created. Most frameworks already
support that but require a lot of boilerplate code to support the different
existing engines. Standardizing will likely increase adoption and will
allow collaboration to make the low-level code that I propose to move in
libphp as fast, stable, and clean as possible.


> Please advise on what the implications would be for the
> non-SAPI-developing PHP devs out there.
>

None, except that they will be able to use the new handle_request()
function to create a worker script if supported by the SAPI they use.

--0000000000008533cb060d54c923--