Re: [PHP-DEV] 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]
Re: [PHP-DEV] RFC proposal: worker mode primitives for SAPIs
On Mon, Jan 1, 2024 at 12:18 PM Rowan Tommins wrote: > > On 31 December 2023 16:31:31 GMT, Pierre Joye wrote: > > >php handles this in threadsafe mode > > Depending on your exact definition of "php", this is either irrelevant or > just plain wrong. > > If you mean "the HTTP SAPIs shipped with official builds of PHP", then it's > true, none handle multiple concurrent requests in a single thread using async > I/O. But none handle multiple consecutive requests in a single thread using a > "worker mode" either, which is the whole point of this conversation. > > If you mean for "php" to include third party HTTP handlers such as > FrankenPHP, then it also includes Swoole, which is what I was describing. > Please someone correct me if I'm wrong, but I understand ReactPHP and AMPHP > also include HTTP servers using the same principle. > > So, to reiterate my point once more: implementations of PHP using async > concurrency are out there already in production use. 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. > > Regards, > > -- > Rowan Tommins > [IMSoP] > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > Hey Rowan, I'm not sure concurrent servers would even be able to be in scope if we wanted them to be? PHP doesn't have an "event-loop", concurrent i/o, or any building blocks needed to serve concurrent requests. It's been made possible through extensions and libraries that aren't maintained by PHP, so I'm not sure how we'd support them directly without those other basic functionalities. If we directly wanted to support concurrent servers, I think there is probably a lot of work to do at a very low level before we could realistically include them in this part of the conversation. Robert Landers Software Engineer Utrecht NL -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] RFC proposal: worker mode primitives for SAPIs
On Mon, Jan 1, 2024, 6:18 PM Rowan Tommins wrote: > On 31 December 2023 16:31:31 GMT, Pierre Joye > wrote: > > >php handles this in threadsafe mode > > Depending on your exact definition of "php", this is either irrelevant or > just plain wrong. > > If you mean "the HTTP SAPIs shipped with official builds of PHP", then > it's true, none handle multiple concurrent requests in a single thread > using async I/O. But none handle multiple consecutive requests in a single > thread using a "worker mode" either, which is the whole point of this > conversation. > 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. I can imagine other developers implement it using other mechanisms (rust or c++ f.e.) but the main interface from a php internal pov remains. It is a first step and based on the usages/feedback, the next steps could be the second part of your comment. Or? best, Pierre >
Re: [PHP-DEV] RFC proposal: worker mode primitives for SAPIs
On 31 December 2023 16:31:31 GMT, Pierre Joye wrote: >php handles this in threadsafe mode Depending on your exact definition of "php", this is either irrelevant or just plain wrong. If you mean "the HTTP SAPIs shipped with official builds of PHP", then it's true, none handle multiple concurrent requests in a single thread using async I/O. But none handle multiple consecutive requests in a single thread using a "worker mode" either, which is the whole point of this conversation. If you mean for "php" to include third party HTTP handlers such as FrankenPHP, then it also includes Swoole, which is what I was describing. Please someone correct me if I'm wrong, but I understand ReactPHP and AMPHP also include HTTP servers using the same principle. So, to reiterate my point once more: implementations of PHP using async concurrency are out there already in production use. 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. Regards, -- Rowan Tommins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
