Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122041
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: Tue, 26 Dec 2023 01:09:37 +0100
Message-ID: <CAPzBOBMRWD_KONGt4GaAUPZ3QQig-VdnN6KU7ihjKH_yjktXOg@mail.gmail.com>
To: Jakub Zelenka <bukka@php.net>
Cc: =?UTF-8?Q?K=C3=A9vin_Dunglas?= <kevin@dunglas.fr>, 
	Larry Garfield <larry@garfieldtech.com>, php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] RFC proposal: worker mode primitives for SAPIs
From: landers.robert@gmail.com (Robert Landers)

Hi Jakub,

> 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.

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).

> 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.

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.

> 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.

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 think this functionality unlocks some really cool potential powers
(in-memory databases for development, connection pooling without an
extension, etc) and it's worth at least seriously considering
implementing it in core.

- Rob