Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126665
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>
In-Reply-To: <CAMW7n8BRwZH64mULctRS4CxOL9TCo5GHvz-ORWHMZr926ZujYw@mail.gmail.com>
Date: Sun, 9 Mar 2025 00:16:37 +0100
Message-ID: <CAAwdEzALuRtkWyw1JgRVVmU9ew8uTiY6DSruR2CKiqNQ03QzOw@mail.gmail.com>
Subject: Re: [PHP-DEV] PHP True Async RFC
To: Edmond Dantes <edmond.ht@gmail.com>
Cc: Daniil Gentili <daniil.gentili@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000e62633062fdcee29"
From: drealecs@gmail.com (=?UTF-8?Q?Alexandru_P=C4=83tr=C4=83nescu?=)

--000000000000e62633062fdcee29
Content-Type: text/plain; charset="UTF-8"

Hi Edmond,

On Sat, Mar 8, 2025, 19:18 Edmond Dantes <edmond.ht@gmail.com> wrote:

> 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.
>
>
> Can you please share a bit more details on how the Scheduler is
implemented, to make sure that I understand why this contradiction exists?
Also with some examples, if possible.

Reading the RFC initially, I though that the Scheduler is using fibers for
everything that runs. And that the Scheduler is the direct parent of all
the fibers that are started using it.
I understood that those fibers needs to be special ones and suspend with a
"Promise-like" object and resume when that is resolved.
You mean that when one of the fibers started by the Scheduler is starting
other fibers they would usually await for them to finish, and that is a
blocking operating that blocks also the Scheduler?
In that sense, any long running blocking operation is not compatible with
the Scheduler...

If you can please explain a bit more with some more details and examples,
it would be great.
Thanks!

-- 
Alex

--000000000000e62633062fdcee29
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">Hi Edmond,<br><br><div class=3D"gmail_quote gmail_quote_c=
ontainer" dir=3D"auto"><div dir=3D"ltr" class=3D"gmail_attr">On Sat, Mar 8,=
 2025, 19:18 Edmond Dantes &lt;<a href=3D"mailto:edmond.ht@gmail.com">edmon=
d.ht@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
dir=3D"ltr">This situation is solely due to the fact that the Scheduler con=
tradicts of Fiber.<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><br></p></div></div></blockquote></div><div class=3D"gmail_quote gmail_q=
uote_container" dir=3D"auto"><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
"><div><p></p></div></div></blockquote></div><div dir=3D"auto">Can you plea=
se share a bit more details on how the Scheduler is implemented, to make su=
re that I understand why this contradiction exists? Also with some examples=
, if possible.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Reading t=
he RFC initially, I though that the Scheduler is using fibers for everythin=
g that runs. And that the Scheduler is the direct parent of all the fibers =
that are started using it.</div><div dir=3D"auto">I understood that those f=
ibers needs to be special ones and suspend with a &quot;Promise-like&quot; =
object and resume when that is resolved.</div><div dir=3D"auto">You mean th=
at when one of the fibers started by the Scheduler is starting other fibers=
 they would usually await for them to finish, and that is a blocking operat=
ing that blocks also the Scheduler?</div><div dir=3D"auto">In that sense, a=
ny long running blocking operation is not compatible with the Scheduler...<=
/div><div dir=3D"auto"><br></div><div dir=3D"auto">If you can please explai=
n a bit more with some more details and examples, it would be great.</div><=
div dir=3D"auto">Thanks!</div><div dir=3D"auto"><br></div><div dir=3D"auto"=
>--=C2=A0</div><div dir=3D"auto">Alex</div><div dir=3D"auto"><br></div><div=
 dir=3D"auto"><br></div><div class=3D"gmail_quote gmail_quote_container" di=
r=3D"auto"></div><div class=3D"gmail_quote gmail_quote_container" dir=3D"au=
to"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex">
</blockquote></div></div>

--000000000000e62633062fdcee29--