Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122037
MIME-Version: 1.0
References: <CADU7aovcatZ++PSg0Pt0-kXJH9Oe09N0jy5uXEoBYoRv6GeUwQ@mail.gmail.com>
 <c100955e-59f6-444d-9b77-c218b7975cd2@app.fastmail.com> <CADU7aos-nuj9Degv2+DHAvTMsMwKnyVJizMeTrKtzvyiRnabUA@mail.gmail.com>
In-Reply-To: <CADU7aos-nuj9Degv2+DHAvTMsMwKnyVJizMeTrKtzvyiRnabUA@mail.gmail.com>
Date: Mon, 25 Dec 2023 17:30:22 +0000
Message-ID: <CAEKnhAHyd+9Y8U5ZfT=QY365MwQu=4kRiGMe+G8UAShdoHnH2g@mail.gmail.com>
To: =?UTF-8?Q?K=C3=A9vin_Dunglas?= <kevin@dunglas.fr>
Cc: Larry Garfield <larry@garfieldtech.com>, php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000050ec74060d58ecfa"
Subject: Re: [PHP-DEV] RFC proposal: worker mode primitives for SAPIs
From: bukka@php.net (Jakub Zelenka)

--00000000000050ec74060d58ecfa
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Dec 25, 2023 at 12:34=E2=80=AFPM K=C3=A9vin Dunglas <kevin@dunglas.=
fr> wrote:

> On Sun, Dec 24, 2023 at 4:21=E2=80=AFPM Larry Garfield <larry@garfieldtec=
h.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
> that
> > shown in the docs page above?  Or would it only work with third party
> SAPIs
> > like FrankenPHP?
>
>
> In theory, PHP-FPM and the Apache module could - like all other SAPIs - b=
e
> enhanced to add a worker mode operating as described in the FrankenPHP do=
c
> thanks to these new primitives.
>

I have been thinking about something similar for FPM and if you had some
sort pool manager process, you could maybe do some sort of initial
execution but then it gets really tricky especially with sharing resources
and managing connections. I think it would be a big can of worms so I don't
think this is going to happen anytime soon. I could imaging that there will
be similar issues for Apache prefork which is likely the most used MPM for
legacy apps. Effectively it means that this function won't be working on
most installations as two of the likely most used SAPI's won't support it.
I think it should be pretty clear from the beginning.


> However, I suggest doing this as a second step, because as described in m=
y
> 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 addi=
ng
> the primitives to libphp, then we'll see how to exploit them (and whether
> it's worthwhile) in the built-in SAPIs.
>

The problem with this is that we would add some code that won't be used by
any of the built in SAPI which means that that we won't be able to have
automated tests for this. So the minimum should be to have at least one
core SAPI supporting this new functionality. I wouldn't mind if it's just a
SAPI for testing purpose which might be actually useful for testing embed
SAPI code. I think that should be a requirement for accepting a PR
introducing this.

It would be also good to put together some base design PR for this as
currently SAPI common functions are implemented separately in each SAPI
(e.g. apache_request_headers). From the linked functionality, it is is not
a big amount of code and seems somehow specific to the FrankenPHP so why
couldn't each SAPI just implement this function separately? I know that
this is not ideal but it's what is already used for apache_request_headers.
I think otherwise you would need some hooking mechanism that should have
some default (which would probably just throw exception) because it is not
going to be implemented by all SAPI's. I think it would be really good if
you could provide more details about planned implementation for this.


> I personally have less interest in working on FPM/CGI/mod_php as the othe=
r
> possibilities offered by modern SAPIs like FrankenPHP are more important
> (better deployment experience as you have a single static binary or Docke=
r
> image, Early Hints support, high-quality native HTTP/3 server etc)
>
>
Except that those are all threaded SAPIs so they offer less separation and
protection against application crashes in addition to the fact that thread
management in PHP still has got its own issues. They are certainly some
advantages especially for thin services but if you have huge monolith
codebase like some big CMS and other projects, then I would probably stick
with process separation model.

Cheers

Jakub

--00000000000050ec74060d58ecfa--