Re: RFC proposal: worker mode primitives for SAPIs

I'm running out of different ways to say the same thing, and not really sure which part of my previous messages people haven't understood. I'm really not saying anything very controversial or complicated, just "had you considered that style B would offer these additional possibilities over style A". So I'm going to quote the parts of previous messages which I think already answer the latest questions. After that, I'm going to leave the thread to others for a bit, unless I see a question that isn't just retreading the same ground. On 01/01/2024 17:36, Pierre Joye wrote:

Unless I misunderstand the current proposal, it is about providing a core interface to allow one to create its own SAPI similar to FrankenPHP, which does not handle request in a singe thread but a thread pool handled by go's coroutine.

From Kévin's opening post:

In addition to FrankenPHP, projects such as RoadRunner and Swoole provide engines supporting worker modes. [...]

the existence of a common infrastructure would standardize the way worker scripts are created and provide a high-level PHP API for writing worker scripts that work with all SAPIs that rely on this new feature.

From my last message:

If we're attempting to standardise a new API for worker modes (i.e. HTTP servers which are no longer "shared nothing"), choosing one which can be used by consecutive worker modes (FrankenPHP , RoadRunner) but not concurrent ones (Swoole, ReactPHP, AMPHP) feels like a big missed opportunity.

On 01/01/2024 17:40, Robert Landers wrote:

I'm not sure concurrent servers would even be able to be in scope if we wanted them to be?

From my message dated 2023-12-29 22:55 UTC:

Note that both async and WebSockets were mentioned as possible "forward compatibility". If we're talking about "next generation SAPIs", these are the kinds of features that people will be - and already are - developing; so it seems foolish not to at least consider them when designing new baseline APIs.

On 01/01/2024 17:36, Pierre Joye wrote:

It is a first step and based on the usages/feedback, the next steps could be the second part of your comment. Or?

From my message dated 2023-12-31 01:20 UTC:

if you standardise on an API that populates global state, you close off any possibility of using that API in a concurrent environment. If you instead standardise on callbacks which hold request and response information in their own scope, you don't close anything off.

And from 2023-12-30 10:53 UTC:

The key requirement is that you have some way of passing the current request and response around as scoped variables, not global state. That's essential for any kind of concurrent run-time (async, thread-aware, etc).

Regards, -- Rowan Tommins [IMSoP]