Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122042
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> <CADU7aou44597+sLDPC0yzAs0sViPUGPmp7TTTb+ih4hJhie_NQ@mail.gmail.com>
In-Reply-To: <CADU7aou44597+sLDPC0yzAs0sViPUGPmp7TTTb+ih4hJhie_NQ@mail.gmail.com>
Date: Tue, 26 Dec 2023 00:29:29 +0000
Message-ID: <CAEKnhAFeZwsnfUeUEmTm1LSpaSYiVy+wnJ1cikC1wt_vSndxBA@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="0000000000003b5f5d060d5ec728"
Subject: Re: [PHP-DEV] RFC proposal: worker mode primitives for SAPIs
From: bukka@php.net (Jakub Zelenka)

--0000000000003b5f5d060d5ec728
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Dec 25, 2023 at 7:06=E2=80=AFPM K=C3=A9vin Dunglas <kevin@dunglas.f=
r> wrote:

>
> On Mon, Dec 25, 2023 at 6:30=E2=80=AFPM Jakub Zelenka <bukka@php.net> wro=
te:
>
>>
>>
>> On Mon, Dec 25, 2023 at 12:34=E2=80=AFPM K=C3=A9vin Dunglas <kevin@dungl=
as.fr> wrote:
>>
>>> On Sun, Dec 24, 2023 at 4:21=E2=80=AFPM Larry Garfield <larry@garfieldt=
ech.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 lik=
e
>>> 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
>>> doc
>>> 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 resourc=
es
>> and managing connections. I think it would be a big can of worms so I do=
n't
>> think this is going to happen anytime soon. I could imaging that there w=
ill
>> be similar issues for Apache prefork which is likely the most used MPM f=
or
>> 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 i=
t.
>> 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 d=
o
>>> 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 wheth=
er
>>> 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 ha=
ve
>> 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 jus=
t a
>> SAPI for testing purpose which might be actually useful for testing embe=
d
>> 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 n=
ot
>> 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_heade=
rs.
>> I think otherwise you would need some hooking mechanism that should have
>> some default (which would probably just throw exception) because it is n=
ot
>> going to be implemented by all SAPI's. I think it would be really good i=
f
>> you could provide more details about planned implementation for this.
>>
>>
>>> I personally have less interest in working on FPM/CGI/mod_php as the
>>> other
>>> possibilities offered by modern SAPIs like FrankenPHP are more importan=
t
>>> (better deployment experience as you have a single static binary or
>>> Docker
>>> 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 certainl=
y
>> some advantages especially for thin services but if you have huge monoli=
th
>> codebase like some big CMS and other projects, then I would probably sti=
ck
>> 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.
>

The way how I read was that this would be eventually supported by all SAPIs
which I think is not likely going to be the case.


> 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.
>
>
+1


> 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?
>

The main does not have a module but it could be probably added to standard
ext like it's the case for other functionality related to main.

Cheers

Jakub

--0000000000003b5f5d060d5ec728--