Hi,
I like it for start a discussion, than it's necessary.
But we need to see the big picture.
The CLI-SAPI is the poor brother in PHP (contrary to other languages),
but that is another discussion than I'll try to open later.
Create a Worker-SAPI?
First any CLI worker can't access the SAPI. So they don't have any benefit.
So Amp, React, Revolt, Workerman, Adapterman, Symfony runtime,... can't
access the internal SAPI functions. Each need to recreate in user land
PHP code for functions that already exist in PHP sapis.
Kudos, for the RFC RFC1867 from Ilija. But we need to go farther.
It isn't possible use header functions :(,
https://github.com/php/php-src/issues/12304
Later we have SAPIs than use PHP embed (really easy to use :)) or in a
similar way.
Here we find 2 ways: forks or threads!!
With forks we can use Super-Globals, with threads it's impossible, and
for that they need to encapsulate it in Request/Response objects.
How we'll join both situations. Here start the discussion.
Forks:
Frankenphp, RoadRunner, Ngx-php (the fastest PHP runtime),...
Nginx Unit still use a shared nothing approach, but it's really easy to
have both.
Threads:
Swoole, OpenSwoole, Swoow,... in that situation the super globals are
NOT possible.
Here some frameworks permit use both (forks or threads) depending on the
master event loop that we choose. But they need to force all to the
threads way to have a unified interface.
We are talking about the main loop, because inside we can use any thread
system.
Thanks to all, and to Kevin to start the discussion.
PD: Actually any new PHP SAPI need to be added to the php-src to have
OPCache enabled. Nginx Unit and other still use cli-server SAPI to have
it. That need to be changed, so any SAPI can call it, without register.
Regards
Joan Miquel
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
