Re: RFC proposal: worker mode primitives for SAPIs

On Mon, Jan 1, 2024 at 12:18 PM Rowan Tommins <rowan.collins@gmail.com> wrote: > > On 31 December 2023 16:31:31 GMT, Pierre Joye <pierre.php@gmail.com> 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