Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126688
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_7ED9BA93-8C20-43E5-88FD-6845DF652F2C"
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.400.131.1.6\))
Subject: Re: [PHP-DEV] PHP True Async RFC
Date: Mon, 10 Mar 2025 11:30:22 +0100
References: <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>
 <77DC5F50-531D-49E8-8BE2-504A19CB5FFD@rwec.co.uk>
 <676e36e4-0b84-4d8c-b3db-2998831cd79d@gmail.com>
 <510B8EF1-9D07-41A8-9EA0-7D99CF7BFC91@rwec.co.uk>
 <bccf099c-55cf-4701-89eb-c26144696eac@gmail.com>
 <4690cff0-7a48-4fe0-8310-688be253f976@gmail.com>
 <CAMW7n8DTVPkA0qk30TCf1+L3Rmooyt5eEMco+=ds_TX3fEXn-Q@mail.gmail.com>
 <4871b2e4-353e-424f-92b9-7e2bb753bafa@gmail.com>
 <CAMW7n8Dzin0sYioWFCJHOfaLASLwuSggijV2=2qQA5tO4a0itA@mail.gmail.com>
To: internals@lists.php.net
In-Reply-To: <CAMW7n8Dzin0sYioWFCJHOfaLASLwuSggijV2=2qQA5tO4a0itA@mail.gmail.com>
Message-ID: <7D224BD3-2FF7-45E8-8D90-C9AEDC80DD4F@gmail.com>
From: daniil.gentili@gmail.com (Daniil Gentili)


--Apple-Mail=_7ED9BA93-8C20-43E5-88FD-6845DF652F2C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> Let me summarize the current state for today:
>=20
> I am abandoning startScheduler and the idea of preserving backward =
compatibility with await_all or anything else in that category. The =
scheduler will be initialized implicitly, and this does not concern =
user-land. Consequently, the spawn function() code will work everywhere =
and always.
>=20

Very glad to hear this, this is the correct approach for concurrency, =
one that will not break all existing libraries and give them the freedom =
to handle their own resource cleanup.

I=E2=80=99ve also seen your latest email about kotlin-like contexts, and =
they also make more sense than an await_all block (which can only cause =
deadlocks): note how a kotlin coroutine context may only be cancelled =
(cancelling all inner coroutines with CancelledExceptions), never =
awaited.

>=20
> >
> >  I can give you several examples where such logic is used in Amphp =
libraries, and it will break if they are invoked within an async block.
> >
>=20
> Got it, it looks like I misunderstood the post due to my focus. So, =
essentially, you're talking not so much about wait_all itself, but =
rather about the parent-child vs. free model.
>=20
> This question is what concerns me the most right now.
>=20
> If you have real examples of how this can cause problems, I would =
really appreciate it if you could share them. Code is the best criterion =
of truth.
>=20

Sure:

- =
https://github.com/amphp/websocket/blob/2.x/src/PeriodicHeartbeatQueue.php=

- https://github.com/amphp/redis/blob/2.x/src/Sync/RedisMutex.php

This is the main example where it is most evident that background fibers =
are needed: logic which requires periodic background pings to be sent in =
order to keep a connection alive, a mutex held or something similar.=20

Constructing a PeriodicHeartbeatQueueinside of a wait_all block invoking =
a a someClass::connect(), storing it in a property and destroying it =
outside of it in someClass::close or someClass::__destruct, would cause =
a deadlock (the EventLoop::repeat doesn=E2=80=99t technically spawn a =
fiber immediately, it spawns one every $interval, but it behaves as =
though a single background fiber is spawned with a sleep($interval), so =
essentially it=E2=80=99s a standalone thread of execution, collected =
only on __destruct).

https://github.com/danog/MadelineProto/tree/v8/src/Loop/Connection =
contains multiple examples of tasks of the same kind in my own library =
(ping loops to keep connections alive, read loops to handle updates =
(which contain vital information needed to keep the client running =
correctly) in the background, etc...), all started on __construct when =
initialising the library, and stopped in __destruct when they are not =
needed anymore.

A coroutine context/scope a-la kotlin is fine, but it should absolutely =
not have anything to await all coroutines in the scope, or else it can =
cause deadlocks with the very common logic listed above.

Regards,
Daniil Gentili.=

--Apple-Mail=_7ED9BA93-8C20-43E5-88FD-6845DF652F2C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; =
charset=3Dutf-8"></head><body style=3D"overflow-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;"><div =
dir=3D"auto" style=3D"overflow-wrap: break-word; -webkit-nbsp-mode: =
space; line-break: after-white-space;"><div dir=3D"auto" =
style=3D"overflow-wrap: break-word; -webkit-nbsp-mode: space; =
line-break: after-white-space;"><div><br></div><blockquote =
type=3D"cite"><div dir=3D"ltr"><ol><p><b>Let me summarize the current =
state for today:</b></p><ol><li><p>I am =
abandoning&nbsp;<code>startScheduler</code>&nbsp;and the idea of =
preserving backward compatibility =
with&nbsp;<code>await_all</code>&nbsp;or anything else in that category. =
The scheduler will be initialized implicitly, and this does not concern =
user-land. Consequently, the&nbsp;<code>spawn =
function()</code>&nbsp;code will work everywhere and =
always.</p></li></ol></ol></div></blockquote><div><br></div>Very glad to =
hear this, this is the correct approach for concurrency, one that will =
not break all existing libraries and give them the freedom to handle =
their own resource cleanup.</div><div dir=3D"auto" style=3D"overflow-wrap:=
 break-word; -webkit-nbsp-mode: space; line-break: =
after-white-space;"><br></div><div dir=3D"auto" style=3D"overflow-wrap: =
break-word; -webkit-nbsp-mode: space; line-break: =
after-white-space;">I=E2=80=99ve also seen your latest email about =
kotlin-like contexts, and they also make more sense than an await_all =
block (which can only cause deadlocks): note how a kotlin coroutine =
context may only be cancelled (cancelling all inner coroutines with =
CancelledExceptions), never awaited.</div><div dir=3D"auto" =
style=3D"overflow-wrap: break-word; -webkit-nbsp-mode: space; =
line-break: after-white-space;"><br></div><div dir=3D"auto" =
style=3D"overflow-wrap: break-word; -webkit-nbsp-mode: space; =
line-break: after-white-space;"><div><blockquote type=3D"cite"><br =
class=3D"Apple-interchange-newline"><div><div =
dir=3D"ltr">&gt;<br>&gt;&nbsp;

I can give you several examples where such logic is used in Amphp =
libraries, and it will break if they are invoked within an async =
block.<br>&gt;<br><br><div><p>Got it, it looks like I misunderstood the =
post due to my focus. So, essentially, you're talking not so much about =
<code>wait_all</code> itself, but rather about the parent-child vs. free =
model.</p><p>This question is what concerns me the most right =
now.</p><p>If you have real examples of how this can cause problems, I =
would really appreciate it if you could share them. Code is the best =
criterion of =
truth.</p></div></div></div></blockquote><div><br></div><div>Sure:</div><d=
iv><br></div><div>- <a =
href=3D"https://github.com/amphp/websocket/blob/2.x/src/PeriodicHeartbeatQ=
ueue.php">https://github.com/amphp/websocket/blob/2.x/src/PeriodicHeartbea=
tQueue.php</a></div><div>-&nbsp;<a =
href=3D"https://github.com/amphp/redis/blob/2.x/src/Sync/RedisMutex.php">h=
ttps://github.com/amphp/redis/blob/2.x/src/Sync/RedisMutex.php</a></div><d=
iv><br></div><div>This is the main example where it is most evident that =
background fibers are needed: logic which requires periodic background =
pings to be sent in order to keep a connection alive, a mutex held or =
something similar.&nbsp;</div><div><br></div><div>Constructing a =
PeriodicHeartbeatQueueinside of a wait_all block invoking a a =
someClass::connect(), storing it in a property and destroying it outside =
of it in someClass::close or someClass::__destruct, would cause a =
deadlock (the EventLoop::repeat doesn=E2=80=99t technically spawn a =
fiber immediately, it spawns one every $interval, but it behaves as =
though a single background fiber is spawned with a sleep($interval), so =
essentially it=E2=80=99s a standalone thread of execution, collected =
only on __destruct).</div><div><br></div><div><a =
href=3D"https://github.com/danog/MadelineProto/tree/v8/src/Loop/Connection=
">https://github.com/danog/MadelineProto/tree/v8/src/Loop/Connection</a>&n=
bsp;contains multiple examples of tasks of the same kind in my own =
library (ping loops to keep connections alive, read loops to handle =
updates (which contain vital information needed to keep the client =
running correctly) in the background, etc...), all started on =
__construct when initialising the library, and stopped in __destruct =
when they are not needed anymore.</div><div><br></div><div>A coroutine =
context/scope a-la kotlin is fine, but it should absolutely not have =
anything to await all coroutines in the scope, or else it can cause =
deadlocks with the very common logic listed =
above.</div><div><br></div><div>Regards,</div><div>Daniil =
Gentili.</div></div></div></div></body></html>=

--Apple-Mail=_7ED9BA93-8C20-43E5-88FD-6845DF652F2C--