Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126673
Precedence: bulk
MIME-Version: 1.0
References: <CAMW7n8AJckEDzhGv9BdjNhq8zAdCqb4HsVr56vGi+izw50X6Dg@mail.gmail.com>
 <9964db8c-0ffe-43d5-8246-47fc76b07180@app.fastmail.com> <CAMW7n8CM7oBfXCDsKtV4hTFs40UmLCU3183WjYE2exLNqKDWLQ@mail.gmail.com>
 <78a03dd0-fd4a-4f4a-ad8a-37e5704f06fc@app.fastmail.com> <CAMW7n8C-Z18MKhyDX2+ofg70cRbwWOk=YWDAZpKtfLZsFVVRng@mail.gmail.com>
 <bb7a9f8f-0422-45e5-b4fc-f5757add92b4@app.fastmail.com> <CAMW7n8BnzL7d0bd_Y_jGOmyWegKQpm-FzrVFRCcDe=bNFZpi+A@mail.gmail.com>
 <08c8ad0b-e8f4-46e3-99f0-b80748d40b89@app.fastmail.com> <07973EAE-2D83-47A8-8FA0-84286C77C02B@rwec.co.uk>
 <48d66433-3ae9-4895-8361-7c81a0a3670d@app.fastmail.com> <be7cb263-93a1-4bd8-9416-ae4d3e0bafe6@rwec.co.uk>
 <dbce8889-016a-4c59-864c-d8fdec895adc@app.fastmail.com> <CAM0Ccxh=bydoDEHBAV+Gb1_86HJjwhW06kzEsdRiMh93k1F7oA@mail.gmail.com>
 <8599eb8b-d4a3-4cb8-899a-25b134e0d64d@gmail.com> <D73BCCC4-3547-45B4-84AD-A5FD6569D43C@rwec.co.uk>
 <74c4c726-63aa-44e0-84c9-840e13a65a4f@gmail.com> <9b7ab30f-5ed6-400d-b941-1291e9185286@app.fastmail.com>
 <9a2e81e8-3534-455b-879a-5a45c85b3ba7@gmail.com> <CAMW7n8BRwZH64mULctRS4CxOL9TCo5GHvz-ORWHMZr926ZujYw@mail.gmail.com>
 <CAAwdEzALuRtkWyw1JgRVVmU9ew8uTiY6DSruR2CKiqNQ03QzOw@mail.gmail.com>
 <CAMW7n8A17ER8vUkNNrEsbkyGm2xY-ZAxkR1_ofWcHmgFbNrzqg@mail.gmail.com> <3384e8b2-5fee-420f-b8cc-e54bba0884db@app.fastmail.com>
In-Reply-To: <3384e8b2-5fee-420f-b8cc-e54bba0884db@app.fastmail.com>
Date: Sun, 9 Mar 2025 11:53:29 +0200
Message-ID: <CAMW7n8D4Df2G_yrJ-Zkcyd5=4DFHZc9uqevZKOZt9defOgg0mQ@mail.gmail.com>
Subject: Re: [PHP-DEV] PHP True Async RFC
To: Rob Landers <rob@bottled.codes>
Cc: =?UTF-8?Q?Alexandru_P=C4=83tr=C4=83nescu?= <drealecs@gmail.com>, 
	Daniil Gentili <daniil.gentili@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000008bad24062fe5d421"
From: edmond.ht@gmail.com (Edmond Dantes)

--0000000000008bad24062fe5d421
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

>
>  Maybe, we could create a different version of fibers ("managed fibers",
maybe?) distinct from the current implementation, with the idea to
deprecate them in PHP 10?
> Then, at least, the scheduler could always be running. If you are using
existing code that
> uses fibers, you can't use the new fibers but it will "just work" if you
aren't using the new fibers (since the scheduler will never pick up those
fibers).
>

Yes, that can be done. It would be good to maintain compatibility with
XDEBUG, but that needs to be investigated.

During our discussion, everything seems to be converging on the idea that
the changes introduced by the RFC into Fiber would be better moved to a
separate class. This would reduce confusion between the old and new
solutions. That way, developers wouldn't wonder why Fiber and coroutines
behave differently=E2=80=94they are simply different classes.

The new *Coroutine* class could have a different interface with new logic.
This sounds like an excellent solution.

The interface could look like this:

   - *suspend* (or another clear name) =E2=80=93 a method that explicitly h=
ands
   over execution to the *Scheduler*.
   - *defer* =E2=80=93 a handler that is called when the coroutine complete=
s.
   - *cancel* =E2=80=93 a method to cancel the coroutine.
   - *context* =E2=80=93 a property that stores the execution context.
   - *parent* (public property or getParent() method) =E2=80=93 returns the=
 parent
   coroutine.

(*Just an example for now.*)

The *Scheduler* would be activated automatically when a coroutine is
created. If the index.php script reaches the end, the interpreter would
wait for the *Scheduler* to finish its work under the hood.

Do you like this approach?

---

Ed.

--0000000000008bad24062fe5d421
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">&gt;=C2=A0<br>&gt;=C2=A0

Maybe, we could create a different version of fibers (&quot;managed fibers&=
quot;, maybe?) distinct from the current implementation, with the idea to d=
eprecate them in PHP 10? <br>&gt; Then, at least, the scheduler could alway=
s be running. If you are using existing code that<br>&gt; uses fibers, you =
can&#39;t use the new fibers but it will &quot;just work&quot; if you aren&=
#39;t using the new fibers (since the scheduler will never pick up those fi=
bers).<br>&gt;<div><br></div><div>Yes, that can be done. It would be good t=
o maintain compatibility with XDEBUG, but that needs to be investigated.=C2=
=A0=C2=A0</div><div><br></div><div>During our discussion, everything seems =
to be converging on the idea that the changes introduced by the RFC into <c=
ode>Fiber</code> would be better moved to a separate class. This would redu=
ce confusion between the old and new solutions. That way, developers wouldn=
&#39;t wonder why <code>Fiber</code> and coroutines behave differently=E2=
=80=94they are simply different classes.</div><div>
<p>The new <strong>Coroutine</strong> class could have a different interfac=
e with new logic. This sounds like an excellent solution.</p>
<p>The interface could look like this:</p>
<ul>
<li><strong><code>suspend</code></strong> (or another clear name) =E2=80=93=
 a method that explicitly hands over execution to the <strong>Scheduler</st=
rong>.</li>
<li><strong><code>defer</code></strong> =E2=80=93 a handler that is called =
when the coroutine completes.</li>
<li><strong><code>cancel</code></strong> =E2=80=93 a method to cancel the c=
oroutine.</li>
<li><strong><code>context</code></strong> =E2=80=93 a property that stores =
the execution context.</li>
<li><strong><code>parent</code></strong> (public property or <code>getParen=
t()</code> method) =E2=80=93 returns the parent coroutine.</li>
</ul>
<p>(<em>Just an example for now.</em>)</p>
<p>The <strong>Scheduler</strong> would be activated automatically when a c=
oroutine is created. If the <code>index.php</code> script reaches the end, =
the interpreter would wait for the <strong>Scheduler</strong> to finish its=
 work under the hood.</p>
<p>Do you like this approach?</p><p>---</p><p>Ed.</p></div></div>

--0000000000008bad24062fe5d421--