Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122039
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>
 <CAEKnhAHyd+9Y8U5ZfT=QY365MwQu=4kRiGMe+G8UAShdoHnH2g@mail.gmail.com>
In-Reply-To: <CAEKnhAHyd+9Y8U5ZfT=QY365MwQu=4kRiGMe+G8UAShdoHnH2g@mail.gmail.com>
Date: Mon, 25 Dec 2023 20:06:16 +0100
Message-ID: <CADU7aou44597+sLDPC0yzAs0sViPUGPmp7TTTb+ih4hJhie_NQ@mail.gmail.com>
To: Jakub Zelenka <bukka@php.net>
Cc: Larry Garfield <larry@garfieldtech.com>, php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000004502e1060d5a436c"
Subject: Re: [PHP-DEV] RFC proposal: worker mode primitives for SAPIs
From: kevin@dunglas.fr (=?UTF-8?Q?K=C3=A9vin_Dunglas?=)

--0000000000004502e1060d5a436c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Dec 25, 2023 at 6:30=E2=80=AFPM Jakub Zelenka <bukka@php.net> wrote=
:

>
>
> On Mon, Dec 25, 2023 at 12:34=E2=80=AFPM K=C3=A9vin Dunglas <kevin@dungla=
s.fr> wrote:
>
>> On Sun, Dec 24, 2023 at 4:21=E2=80=AFPM Larry Garfield <larry@garfieldte=
ch.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 - =
be
>> enhanced to add a worker mode operating as described in the FrankenPHP d=
oc
>> 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 resource=
s
> 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 wi=
ll
> be similar issues for Apache prefork which is likely the most used MPM fo=
r
> 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 =
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 whethe=
r
>> it's worthwhile) in the built-in SAPIs.
>>
>
> The problem with this is that we would add some code that won't be used b=
y
> 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 no=
t
> 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_header=
s.
> I think otherwise you would need some hooking mechanism that should have
> some default (which would probably just throw exception) because it is no=
t
> 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 oth=
er
>> possibilities offered by modern SAPIs like FrankenPHP are more important
>> (better deployment experience as you have a single static binary or Dock=
er
>> image, Early Hints support, high-quality native HTTP/3 server etc)
>>
>>
> Except that those are all threaded SAPIs so they offer less separation an=
d
> protection against application crashes in addition to the fact that threa=
d
> 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 stic=
k
> with process separation model.
>
> Cheers
>
> Jakub
>

Sure, the main targets are new SAPIs like FrankenPHP and the one in Rust
developed by the RoadRunner team. I thought it was clear in my previous
messages but I'll be glad to make it bold in the RFC.
Automated tests (likely through a test SAPI) will definitely be needed.
Throwing if the current SAPI doesn't support (yet) the new userland
function looks sensitive.

Couldn't this shared code be put in "main", as it could (theoretically, I
agree that it will be hard to do for existing core SAPIs) be used by all
SAPIs?

--0000000000004502e1060d5a436c--