Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122062
MIME-Version: 1.0
References: <CADU7aovcatZ++PSg0Pt0-kXJH9Oe09N0jy5uXEoBYoRv6GeUwQ@mail.gmail.com>
 <5060b986-2e5a-46e4-9c83-763e5b155e83@gmail.com>
In-Reply-To: <5060b986-2e5a-46e4-9c83-763e5b155e83@gmail.com>
Date: Fri, 29 Dec 2023 22:14:34 +0100
Message-ID: <CADU7aoutXwr2puZnzMJk+iNfxf-xE-2DKviSTHLK+TR3xpzsQA@mail.gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000791f38060dac8508"
Subject: Re: [PHP-DEV] RFC proposal: worker mode primitives for SAPIs
From: kevin@dunglas.fr (=?UTF-8?Q?K=C3=A9vin_Dunglas?=)

--000000000000791f38060dac8508
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Dec 29, 2023 at 8:14=E2=80=AFPM Rowan Tommins <rowan.collins@gmail.=
com>
wrote:

> - FrankenPHP expects the user to manage the main event loop, repeatedly
> passing the server a function to be called once; it doesn't pass
> anything into or out of the userland handler, instead resetting global
> state to mimic a non-worker environment
> [https://frankenphp.dev/docs/worker/#custom-apps]
>

This isn't exact. FrankenPHP does manage the event loop (the Go runtime
manages it - through a channel - under the hood).
The frankenphp_handle_request() pauses the thread until the Go runtime
gives back control to the C thread (when a request is dispatched to this
worker).
It's actually very similar to WSGI.

As I explained in my previous messages, it's expected that other SAPIs
handle the event loop too (using the primitives provided by the language
they are written in).


> - RoadRunner doesn't use a callback at all, instead providing methods to
> await a request and provide a response; it directly uses PSR-7 and
> PSR-17 objects [https://roadrunner.dev/docs/php-worker/current/en]
> - OpenSwoole manages the main loop itself, and uses lifecycle events to
> interface to userland code; the HTTP 'Request' event is passed custom
> Request and Response objects
> [https://openswoole.com/docs/modules/swoole-http-server-on-request]
>

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.
If PHP adds a higher-level API at some point, we'll be able to upgrade this
part as every other part of the PHP code base. But it's an unrelated topic:
having such higher-level representations of HTTP messages would be
beneficial both in "normal" and in "worker" mode.


> it would be adapted for an async PHP environment, or with WebSockets,
> for instance.
>

I'm not sure what you mean by "async PHP environment".
WebSockets and WebTransport are a different kind of beast, they are much
lower level than HTTP and will require a different API anyway (and probably
a lot of other adaptations in core) to be supported in PHP.
In Go, for instance, the WebSocket and WebTransport APIs aren't the same as
the HTTP API.

Best regards,

--000000000000791f38060dac8508--