Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126557
Content-Type: multipart/alternative;
 boundary="----sinikael-?=_1-17410319664900.013714842001225191"
Message-ID: <1741029042833.2240251697.2286506290@gmail.com>
To: Nicolas Grekas <nicolas.grekas+php@gmail.com>
Cc: Daniil Gentili <daniil@daniil.it>, internals@lists.php.net
Subject: Re: [PHP-DEV] PHP True Async RFC
Date: Mon, 03 Mar 2025 19:59:26 +0000
In-Reply-To:
 <CAOWwgpkOCKuDPsid=kr6arcUFw7F_+KD_X=qAX_aKn9G94CHKg@mail.gmail.com>
References:
 <CAOWwgpkOCKuDPsid=kr6arcUFw7F_+KD_X=qAX_aKn9G94CHKg@mail.gmail.com>
User-Agent: Vivaldi Mail/7.1.3570.50
Precedence: bulk
MIME-Version: 1.0
From: edmond.ht@gmail.com (Edmond Dantes)

------sinikael-?=_1-17410319664900.013714842001225191
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi, Nicolas.


Hi Edmond,


The target DX is that when outside any event loop, we're still able to 
leverage fibers to provide concurrency, for requests only, and when inside 
an event loop, requests run concurrently to any other things that the loop 
monitors.


Is that something that could be achieved with your proposal?
If not, maybe that's the split we're wondering about?






This RFC leads to PHP operating in two modes:

Blocking mode: The Event Loop needs to be implemented manually, AMPHP 
works. This is how PHP currently operates.
Concurrent mode: Code runs in coroutines. The Event Loop works under the 
hood. AMPHP does not work.

If we try to imagine a way to keep PHP in a single mode, it would likely 
require implementing coroutines separately from Fiber and leaving Fiber as 
legacy.

This solution has both advantages and disadvantages.

Advantages:

Switching can be optimized considering the new architecture.
The Event Loop will start automatically when needed.
Code using Fiber will work as before, and most likely, AMPHP will be able 
to create an event loop in user-land.

Disadvantages:

More work is required.
There is a risk of ending up with a Frankenstein-like result. :)



A relative advantage of the current implementation is that it changes only 
about 100-500 lines in the PHP core (probably even fewer, since part of the 
changes are in extensions like CURL and Socket).

The downside is that it cannot change the rules that were previously 
established.

-- 
Ed.
------sinikael-?=_1-17410319664900.013714842001225191
Content-Type: text/html; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

<html><head></head><body><div>Hi, Nicolas.</div><span 
class="viv-signature"></span><br><blockquote style="margin: 0 0 0.80ex; 
border-left: #0000FF 2px solid; padding-left: 1ex"><div dir="ltr"><div>Hi 
Edmond,</div><div><br></div><div><div class="gmail_quote 
gmail_quote_container"><div><span style="background-color: 
var(--colorBgIntense); color: var(--colorFgIntense);">The target DX is that 
when outside any event loop, we're still able to leverage fibers to provide 
concurrency, for requests only, and when inside an event loop, requests run 
concurrently to any other things that the loop 
monitors.</span></div><div><br></div><div>Is that something that could be 
achieved with your proposal?</div><div>If not, maybe that's the split we're 
wondering about?</div><div><br><br></div></div></div></div>
</blockquote><span class="viv-signature-below"><div><span 
class="viv-signature-below"><br></span></div><div><span 
class="viv-signature-below"><p data-end="47" data-start="0">This RFC leads 
to PHP operating in two modes:</p><ol data-end="279" data-start="49"><li 
data-end="170" data-start="49"><strong data-end="69" 
data-start="52">Blocking mode</strong>: The Event Loop needs to be 
implemented manually, AMPHP works. This is how PHP currently 
operates.</li><li data-end="279" data-start="171"><strong data-end="193" 
data-start="174">Concurrent mode</strong>: Code runs in coroutines. The 
Event Loop works under the hood. AMPHP does not work.</li></ol><p 
data-is-only-node="" data-is-last-node="" data-end="436" 
data-start="281">If we try to imagine a way to keep PHP in a single mode, 
it would likely require implementing coroutines separately from Fiber and 
leaving Fiber as legacy.</p><p data-end="54" data-start="0">This solution 
has both advantages and disadvantages.</p><p data-end="73" 
data-start="56"><strong data-end="71" 
data-start="56">Advantages:</strong></p><ol data-end="314" 
data-start="74"><li data-end="139" data-start="74">Switching can be 
optimized considering the new architecture.</li><li data-end="197" 
data-start="140">The Event Loop will start automatically when 
needed.</li><li data-end="314" data-start="198">Code using Fiber will work 
as before, and most likely, AMPHP will be able to create an event loop in 
user-land.</li></ol><p data-end="336" data-start="316"><strong 
data-end="334" data-start="316">Disadvantages:</strong></p><ul 
data-is-only-node="" data-is-last-node="" data-end="430" 
data-start="337"><li data-end="363" data-start="337">More work is 
required.</li><li data-is-last-node="" data-end="430" 
data-start="364">There is a risk of ending up with a Frankenstein-like 
result. :)</li></ul></span></div><div><span 
class="viv-signature-below"><br></span></div><div><span 
class="viv-signature-below"><p data-end="201" data-start="0">A relative 
advantage of the current implementation is that it changes only about 
100-500 lines in the PHP core (probably even fewer, since part of the 
changes are in extensions like CURL and Socket).</p><p data-end="286" 
data-start="203">The downside is that it cannot change the rules that were 
previously 
established.</p></span></div>--&nbsp;<br>Ed.</span></body></html>
------sinikael-?=_1-17410319664900.013714842001225191--