Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122043
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> <CAPzBOBMRWD_KONGt4GaAUPZ3QQig-VdnN6KU7ihjKH_yjktXOg@mail.gmail.com>
In-Reply-To: <CAPzBOBMRWD_KONGt4GaAUPZ3QQig-VdnN6KU7ihjKH_yjktXOg@mail.gmail.com>
Date: Tue, 26 Dec 2023 00:41:35 +0000
Message-ID: <CAEKnhAHrHrmpMVNSs_9Jt5815jZz93dOZrOd1D7SMvundShQTw@mail.gmail.com>
To: Robert Landers <landers.robert@gmail.com>
Cc: =?UTF-8?Q?K=C3=A9vin_Dunglas?= <kevin@dunglas.fr>, 
	Larry Garfield <larry@garfieldtech.com>, php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000007e30e8060d5ef213"
Subject: Re: [PHP-DEV] RFC proposal: worker mode primitives for SAPIs
From: bukka@php.net (Jakub Zelenka)

--0000000000007e30e8060d5ef213
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

On Tue, Dec 26, 2023 at 12:09=E2=80=AFAM Robert Landers <landers.robert@gma=
il.com>
wrote:

> Hi Jakub,
>
> > I have been thinking about something similar for FPM and if you had som=
e
> > 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.
>
> It's already happening. Most libraries (particularly popular ones in
> the Symfony/Laravel world) already support most of this
> out-of-the-box. I love stateless servers, but sometimes a stateful
> server is better. What is really nice about worker mode is that you
> can actually have a PHP-native in-memory database that only exists for
> as long as the worker is running (I do this for some unit tests).
>
>
This was just about FPM. What I meant that this is not going to be
supported by FPM anytime soon if ever.


> > 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 o=
n
> > 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.
>
> Most people are familiar with fastcgi_finish_request() and there are
> some built-in SAPI's that don't support it. I don't think that just
> because it won't start out with full support, it should be discarded.
>
>
I didn't mean that it shouldn't be added. It should just be clear from the
beginning that this will be for limited set of SAPIs.


> > 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 wh=
y
> > 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 hav=
e
> > 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.
>
> Most (all?) modern SAPI (lightspeed, roadrunner, etc) implements
> fastcgi_finish_request(), even if no fastcgi is involved, simply
> because of backward compatibility. It'd be great to actually bikeshed
> a decent name and syntax/semantics before something popular comes
> along and forces us all to use frankenphp_handle_request() or
> something, simply because of backward compatibility.
>

I agree that coming up with some sensible name and API would be a good
think even though it will have limited use in core. And if it gives us some
coverage of embed SAPI (libphp), then it's even better.

Cheers

Jakub

--0000000000007e30e8060d5ef213--