Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122068
MIME-Version: 1.0
References: <CADU7aovcatZ++PSg0Pt0-kXJH9Oe09N0jy5uXEoBYoRv6GeUwQ@mail.gmail.com>
 <5060b986-2e5a-46e4-9c83-763e5b155e83@gmail.com> <CADU7aoutXwr2puZnzMJk+iNfxf-xE-2DKviSTHLK+TR3xpzsQA@mail.gmail.com>
 <6f7815b9-80cc-4e08-819a-49dca090116f@gmail.com>
In-Reply-To: <6f7815b9-80cc-4e08-819a-49dca090116f@gmail.com>
Date: Sat, 30 Dec 2023 10:59:07 +0100
Message-ID: <CAPzBOBMzL78Fxb+sDTyfCoR0psKzkp8o50+RwQ2Y3Sz+K+7jUQ@mail.gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Cc: internals@lists.php.net, =?UTF-8?Q?K=C3=A9vin_Dunglas?= <kevin@dunglas.fr>
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)

> >     - FrankenPHP expects the user to manage the main event loop ...
> >
> >
> > This isn't exact. FrankenPHP does manage the event loop (the Go
> > runtime manages it - through a channel - under the hood).
>
>
> Perhaps "event loop" was the wrong term; what I was highlighting is that
> to use FrankenPHP or RoadRunner, you have to write a while loop, which
> explicitly handles one request at a time. In Swoole, there is no such
> loop: you register event handlers and then call $server->run() once.
> Similarly, WSGI mandates that the server "invokes the application
> callable once for each request it receives from an HTTP client".
>
> It's a distinction of pull/poll (the application must actively block
> until next request) vs push/subscribe (the application is passively
> invoked whenever needed).

I think these models have different capabilities: A pull/poll model is
quite simple, while a subscription model is usually more complex.

With something simple like in FrankenPHP, creating a Queue SAPI, a
WebSocket SAPI, etc isn't far off, where someone writes some PHP to
consume a queue or websocket connections.

> > I already replied to Crell about that. It will totally possible to
> > expose more complex HTTP message objects in the future,
> > but PHP currently lacks such objects. The only things we have are
> > superglobals (which are more or less similar to CGI variables, as done
> > in WSGI) and streams. It's why we're using them.
>
>
> The use of objects vs arrays wasn't the main difference I was trying to
> highlight there, but rather the overall API of how information gets into
> and out of the application. FrankenPHP is the only server listed which
> needs to reset global state on each request, because the others
> (including Python WSGI and ASGI) use non-global variables for both input
> and output.
>
> I notice that the Laravel Octane adaptor for FrankenPHP takes that
> global state and immediately converts it into non-global variables for
> consumption by the application.

For this to happen in PHP Core, there would need to be request objects
instead of a global state. If an RFC implementing PSR
requests/responses in Core is a pre-requisite for enabling what we're
discussing here, I'd personally be all for that (as would a very large
chunk of the PHP community, IMHO). I personally think this is a
chicken/egg type of problem though. It doesn't make sense to have
request/response objects right now, and I get the feeling that people
would only support worker mode primitives if there were request
objects... so, it might make sense to build a v1 of the worker mode
primitives and then iterate towards request objects, because then
there would be an actual need for them.

Robert Landers
Software Engineer
Utrecht NL