Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126600
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_FEAEF86B-6D18-4C4E-B273-B53164DDF16D"
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: Thu, 6 Mar 2025 11:00:07 +0100
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>
To: internals@lists.php.net
In-Reply-To: <CAMW7n8C-Z18MKhyDX2+ofg70cRbwWOk=YWDAZpKtfLZsFVVRng@mail.gmail.com>
Message-ID: <20730F0A-0A5F-4DA0-BD07-357DC30E3CB4@gmail.com>
From: daniil.gentili@gmail.com (Daniil Gentili)


--Apple-Mail=_FEAEF86B-6D18-4C4E-B273-B53164DDF16D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> Of course, this is not an elegant solution, as it adds one more rule =
to the language, making it more complex. However, from a legacy =
perspective, it seems like a minimal scar.
> (to All: Please leave your opinion if you are reading this )
>=20
Larry=E2=80=99s approach seems like a horrible idea to me: it increases =
complexity, prevents easy migration of existing code to an asynchronous =
model and is incredibly verbose for no good reason.

The arguments mentioned in =
https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-co=
nsidered-harmful/ are not good arguments at all, as they essentially =
propose explicitly reducing concurrency (by allowing it only within =
async blocks) or making it harder to use by forcing users to pass around =
contexts (which is even worse than function colouring =
https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/=
).
This (supposedly) reduces issues with resource contention/race =
conditions: sure, if you don=E2=80=99t use concurrency or severely limit =
it, you will have less issues with race conditions, but that=E2=80=99s =
not an argument in favour of nurseries, that=E2=80=99s an argument =
against concurrency.

Race conditions and deadlocks are possible either way when using =
concurrency, and the way to avoid them is to introduce synchronisation =
primitives (locks, mutexes similar to the ones in =
https://github.com/amphp/sync/, or lockfree solutions like actors, which =
I am a heavy user of), not bloating signatures by forcing users to pass =
around contexts, reducing concurrency and completely disallowing global =
state.

Golang is the perfect example of a language that does colourless, =
(mostly) contextless concurrency without the need for coloured =
(async/await keywords) functions and other complications.
Race conditions are deadlocks are avoided, like in any concurrent model, =
by using appropriate synchronisation primitives, and by communicating =
with channels (actor model) instead of sharing memory, where =
appropriate.

Side note, I *very* much like the current approach of implicit =
cancellations, because they even remove the need to pass contexts to =
make use of cancellations, like in golang or amphp (though the RFC could =
use some further work regarding cancellation inheritance between fibers, =
but that=E2=80=99s a minor issue).

> Yeah, so basically, you're creating the service again and again for =
each coroutine if the coroutine needs to use it. This is a good solution =
in the context of multitasking, but it loses in terms of performance and =
memory, as well as complexity and code size, because it requires more =
factory classes.
>=20
^ this

Regarding backwards compatibility (especially with revolt), since I also =
briefly considered submitting an async RFC and thought about it a bit, I =
can suggest exposing an event loop interface like =
https://github.com/revoltphp/event-loop/blob/main/src/EventLoop.php, =
which would allow userland event loop implementations to simply switch =
to using the native event loop as backend (this=E2=80=99ll be especially =
simple to do for which is the main user of fibers, revolt, since the =
current implementation is clearly inspired by revolt=E2=80=99s event =
loop).=20

Essentially, the only thing that=E2=80=99s needed for =
backwards-compatibility in most cases is an API that can be used to =
register onWritable, onReadable callbacks for streams and a way to =
register delayed (delay) tasks, to completely remove the need to invoke =
stream_select.

I=E2=80=99d recommend chatting with Aaron to further discuss backwards =
compatibility and the overall RFC: I=E2=80=99ve already pinged him, =
he=E2=80=99ll chime in once he has more time to read the RFC.

~~~

To Edmond, as someone who submitted RFCs before: stand your ground, try =
not to listen too much to what people propose in this list, especially =
if it=E2=80=99s regarding radical changes like Larry's; avoid bloating =
the RFC with proposals that you do not really agree with.


Regards,
Daniil Gentili

=E2=80=94

Daniil Gentili - Senior software engineer=20

Portfolio: https://daniil.it <https://daniil.it/>
Telegram: https://t.me/danogentili=

--Apple-Mail=_FEAEF86B-6D18-4C4E-B273-B53164DDF16D
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;"><br><div><div><blockquote type=3D"cite"><div>Of =
course, this is not an elegant solution, as it adds one more rule to the =
language, making it more complex. However, from a legacy perspective, it =
seems like a minimal scar.</div><div><div dir=3D"ltr"><p>(to All: Please =
leave your opinion if you are reading this =
)<br></p></div></div></blockquote><div>Larry=E2=80=99s approach seems =
like a horrible idea to me: it increases complexity, prevents easy =
migration of existing code to an asynchronous model and is incredibly =
verbose for no good reason.</div><div><br></div><div><div>The arguments =
mentioned in&nbsp;<a =
href=3D"https://vorpus.org/blog/notes-on-structured-concurrency-or-go-stat=
ement-considered-harmful/">https://vorpus.org/blog/notes-on-structured-con=
currency-or-go-statement-considered-harmful/</a>&nbsp;are not good =
arguments at all, as they essentially propose explicitly reducing =
concurrency (by allowing it only within async blocks) or making it =
harder to use by forcing users to pass around contexts (which is even =
worse than function colouring&nbsp;<a =
href=3D"https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-f=
unction/">https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your=
-function/</a>).</div><div>This (supposedly) reduces issues with =
resource contention/race conditions: sure, if you don=E2=80=99t use =
concurrency or severely limit it, you will have less issues with race =
conditions, but that=E2=80=99s not an argument in favour of nurseries, =
that=E2=80=99s an argument against =
concurrency.</div><div><br></div><div>Race conditions and deadlocks are =
possible either way when using concurrency, and the way to avoid them is =
to introduce synchronisation primitives (locks, mutexes similar to the =
ones in&nbsp;<a =
href=3D"https://github.com/amphp/sync/">https://github.com/amphp/sync/</a>=
, or lockfree solutions like actors, which I am a heavy user of), not =
bloating signatures by forcing users to pass around contexts, reducing =
concurrency and completely disallowing global =
state.</div><div><br></div><div>Golang is the perfect example of a =
language that does colourless, (mostly) contextless concurrency without =
the need for coloured (async/await keywords) functions and other =
complications.</div><div>Race conditions are deadlocks are avoided, like =
in any concurrent model, by using appropriate synchronisation =
primitives, and by communicating with channels (actor model) instead of =
sharing memory, where appropriate.</div><div><br></div><div>Side note, I =
*very* much like the current approach of implicit cancellations, because =
they even remove the need to pass contexts to make use of cancellations, =
like in golang or amphp (though the RFC could use some further work =
regarding cancellation inheritance between fibers, but that=E2=80=99s a =
minor issue).</div><div><br></div><div><blockquote type=3D"cite"><div =
dir=3D"ltr"><p>Yeah, so basically, you're creating the service again and =
again for each coroutine if the coroutine needs to use it. This is a =
good solution in the context of multitasking, but it loses in terms of =
performance and memory, as well as complexity and code size, because it =
requires more factory classes.</p></div></blockquote><div>^ =
this</div><div><br></div></div><div>Regarding backwards compatibility =
(especially with revolt), since I also briefly considered submitting an =
async RFC and thought about it a bit, I can suggest exposing an event =
loop interface like&nbsp;<a =
href=3D"https://github.com/revoltphp/event-loop/blob/main/src/EventLoop.ph=
p">https://github.com/revoltphp/event-loop/blob/main/src/EventLoop.php</a>=
, which would allow userland event loop implementations to simply switch =
to using the native event loop as backend (this=E2=80=99ll be especially =
simple to do for which is the main user of fibers, revolt, since the =
current implementation is clearly inspired by revolt=E2=80=99s event =
loop).&nbsp;</div><div><br></div><div>Essentially, the only thing =
that=E2=80=99s needed for backwards-compatibility in most cases is an =
API that can be used to register onWritable, onReadable callbacks for =
streams and a way to register delayed (delay) tasks, to completely =
remove the need to invoke stream_select.</div><div><br></div><div>I=E2=80=99=
d recommend chatting with Aaron to further discuss backwards =
compatibility and the overall RFC: I=E2=80=99ve already pinged him, =
he=E2=80=99ll chime in once he has more time to read the =
RFC.</div><div><br></div></div>~~~</div><div><br></div><div>To Edmond, =
as someone who submitted RFCs before: stand your ground, try not to =
listen too much to what people propose in this list, especially if =
it=E2=80=99s regarding radical changes like Larry's; avoid bloating the =
RFC with proposals that you do not really agree =
with.</div><div><br></div><br><div>Regards,<br>Daniil =
Gentili<br><br><div>=E2=80=94</div><div><br></div><div>Daniil Gentili - =
Senior software engineer&nbsp;</div><div><br>Portfolio:&nbsp;<a =
href=3D"https://daniil.it/">https://daniil.it</a></div><div>Telegram:&nbsp=
;<a =
href=3D"https://t.me/danogentili">https://t.me/danogentili</a></div></div>=
</div></body></html>=

--Apple-Mail=_FEAEF86B-6D18-4C4E-B273-B53164DDF16D--