Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126655
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>
In-Reply-To: <9a2e81e8-3534-455b-879a-5a45c85b3ba7@gmail.com>
Date: Sat, 8 Mar 2025 20:16:14 +0200
Message-ID: <CAMW7n8BRwZH64mULctRS4CxOL9TCo5GHvz-ORWHMZr926ZujYw@mail.gmail.com>
Subject: Re: [PHP-DEV] PHP True Async RFC
To: Daniil Gentili <daniil.gentili@gmail.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000b17512062fd8bcde"
From: edmond.ht@gmail.com (Edmond Dantes)

--000000000000b17512062fd8bcde
Content-Type: text/plain; charset="UTF-8"

>
>  This also seems like a very bad idea: there is no reason for the
language hide concurrency behind an INI or even worse a compilation flag.
>

This is not because someone wants it that way. This situation is solely due
to the fact that the Scheduler contradicts of Fiber.

   - The Scheduler expects to switch contexts as it sees fit.
   - Fiber expects context switching to occur only between the Fiber-parent
   and its child.

Of course, the switching mechanism can be modified, and the logic of the
main context can also be changed. The problem is that, at a logical level,
these two approaches are mutually exclusive.

For example, the Swow project introduced a separate coroutine library
(libcat) and abandoned Fiber. But we cannot do the same.

---

Ed.

--000000000000b17512062fd8bcde
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">&gt;<br>&gt;=C2=A0

This also seems like a very bad idea: there is no reason for the language h=
ide concurrency behind an INI or even worse a compilation flag.<br>&gt;<div=
><br></div><div>This is not because someone wants it that way. This situati=
on is solely due to the fact that the Scheduler contradicts of Fiber.</div>=
<div>
<ul>
<li>The Scheduler expects to switch contexts as it sees fit.</li>
<li>Fiber expects context switching to occur only between the Fiber-parent =
and its child.</li>
</ul>
<p>Of course, the switching mechanism can be modified, and the logic of the=
 main context can also be changed. The problem is that, at a logical level,=
 these two approaches are mutually exclusive.</p>
<p>For example, the Swow project introduced a separate coroutine library (l=
ibcat) and abandoned Fiber. But we cannot do the same.=C2=A0</p><p>---</p><=
p>Ed.</p></div></div>

--000000000000b17512062fd8bcde--