Re: RFC proposal: worker mode primitives for SAPIs

> Le 4 janv. 2024 à 18:21, Joanhey <joanhey@kumbiaphp.com> a écrit : > > 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 Thanks for the summary! For the record, FrankenPHP and NGINX Unit use threads, not forks (and recommend ZTS PHP builds). And as far as I understand, Swoole etc use a reactor pattern and non-blocking IOs, not threads. Also Symfony Runtime isn’t an engine but a library with adapters for FrankenPHP, RoadRunner, Bref etc. The main SAPI using libphp is the embed SAPI, but some non-core SAPIs including FrankenPHP, NGINX Unit and uWSGI use libphp with their own SAPIs. The confusing part is that you need to enable the embed SAPI through the configure options to build libphp, even if the embed SAPI itself isn’t used. Best regards,