Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126600
X-Original-To: internals@lists.php.net
Delivered-To: internals@lists.php.net
Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5])
	by qa.php.net (Postfix) with ESMTPS id BA8911A00BC
	for <internals@lists.php.net>; Thu,  6 Mar 2025 10:00:29 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail;
	t=1741255073; bh=oT4ceSU+Gzvrv3evnDp8kNP1GRfhQk4n2k6vxx8GZJc=;
	h=From:Subject:Date:References:To:In-Reply-To:From;
	b=brPVvYAlxY0xaK631WxyeIvFkOoMCWkmmu2JEeUuK+NsKKk60axXctwCrAeHTpKAr
	 gCWkjCFA0Veu8oJ8eNggSzaYvS6aw3r3EZ7NlWR1RJgV8KyE3cuIe8T7rX1YWZz6i+
	 y4rd58RCG1UyZM0hgnJn8gGjBsXUMaa8WNB7s18HQPblJplDZU3TZ//RyOw82vfJIt
	 U1htp1IIfIzTnzeqhAN0X+UG5bYNsON04EDDmEjtwlqSaCgUk5ItEGfOmJEbUe983Q
	 Hp5gNOKasaGJ2m0Txyav6J6KdAWixMu9fUyjzVpCfFdkk/tPnNNkACdpl7/aGHK7o8
	 E23wuny7+9woA==
Received: from php-smtp4.php.net (localhost [127.0.0.1])
	by php-smtp4.php.net (Postfix) with ESMTP id 366C018005B
	for <internals@lists.php.net>; Thu,  6 Mar 2025 09:57:51 +0000 (UTC)
X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on php-smtp4.php.net
X-Spam-Level: 
X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_50,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS,FREEMAIL_FROM,
	HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,
	SPF_PASS,URIBL_SBL_A autolearn=no autolearn_force=no version=4.0.0
X-Spam-Virus: No
X-Envelope-From: <daniil.gentili@gmail.com>
Received: from mail-ed1-f43.google.com (mail-ed1-f43.google.com [209.85.208.43])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by php-smtp4.php.net (Postfix) with ESMTPS
	for <internals@lists.php.net>; Thu,  6 Mar 2025 09:57:45 +0000 (UTC)
Received: by mail-ed1-f43.google.com with SMTP id 4fb4d7f45d1cf-5e52c1c3599so626360a12.2
        for <internals@lists.php.net>; Thu, 06 Mar 2025 02:00:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1741255220; x=1741860020; darn=lists.php.net;
        h=message-id:in-reply-to:to:references:date:subject:mime-version:from
         :from:to:cc:subject:date:message-id:reply-to;
        bh=6Q4B+77jaTUbky1pPBogWaAK6UXn/iyPJ72WAAVFbe8=;
        b=VKNUPB4ogPaKs+p6kqmLZgvEZie1u6S4xb+J1ItFDsVf/aeobBBdBrPq/jWDyYSNr7
         MweFv3FEzLbhrrnNzvlPHjmHRvM3957ixjsJMJLTXHMTTVa/PCuAKntQR57N9ZfX6Rb2
         EJTc996FcwLyxFNq4p6izdluX8sWJn9ozqVoJP0nKdGFoQ3Pkpwkt7CpJQuPnoNW33nB
         GesrnIAeMkbxoImuF0O+54APT44cYZN3Dapm5HreGQJ/8DkjjYZ3d3TBKg7WmrIqlLV9
         Zk1mEijV2hAMUb0km+Aw1Pxiyk1kwVqUL2A9ros2qMwf52TCnGNzusm5NfvYRJNCoXVD
         YLpA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1741255220; x=1741860020;
        h=message-id:in-reply-to:to:references:date:subject:mime-version:from
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=6Q4B+77jaTUbky1pPBogWaAK6UXn/iyPJ72WAAVFbe8=;
        b=hFd8g7ujoEhelRE0dhHrC0XbgJ/Lx5NMRM4M52jCDJMJYtxfRdD4c9Ga4queAjBjSm
         GYcTG0JwwNfIUaQFz2doTTDbjtLzPJYXf3hX9z07LmGTYiqg7kycRf3V4JKBwP4S80j/
         oYdgbgQogEEoKsUTOQBYK67bm1PHO8yMJhBbIJ9KDN3b04j2HuBm+fG9cTVqDRpsvkML
         cfld+1q+266u8vU5yte7XCmygJipkk7WuTTEQxbRhgD2pHlUqdf3mGKeN5SOyFSVswki
         7TNwHJFsXnnm+RkArXyidI2m6dqno1wDaHGIXLw90lByfx2wnH7CEcQfdUdISDFbZWOY
         aIjQ==
X-Gm-Message-State: AOJu0Yy7mY/BLAAmrX15EDIJ+/MHUR8L6d7jDP8DmKIWkCs2XLO6qZGC
	TUONmmWu8LuOSbnp1jFRDDKt/cy9PyQf+u6y65YC2mVl0vKMGImdeQBRTg==
X-Gm-Gg: ASbGncv6ucf0T+gTgIMpoJ3BNJRhtFovhRPjppNZlSlExInT0Kv6gRj5y8BitQeqG0D
	8Zwq4uk/Mq+LnWjmNgGjlPdX9ereckFvwAgxUrC6RLYvwnJEcZKsEKuhzB/u/NcE7opX52/LWix
	+45X6MDQNqq6UggfctXxp7h2kErqRbwZWuuByTz8DyXvpRpdwSFiftLXlI+fl+HHy0NbYF0tIgP
	YAKjhAh/48yo7C6Xk4RMPpIsLw46pVKV0G4Ofd4PUjCyouOYOyf7/i7qcePwMTd+zAQyiWQz+VZ
	5sHf0BqvLLaf7io3GCHIQa/MgfwImQeJly0GKGXCO8zuBngiC2/v30wCkcpwzKH7DSnvV0bgJSQ
	AT4L3ujiHmYTw7rVzwy7mVVUbW7eJeV4+ep5ss9w+oRvmCY9xp4jmmBU=
X-Google-Smtp-Source: AGHT+IFHW8oDXqs8peZn+sVu9Ypwa4x0dcHB8kNP59s0sm4/xUMJ/Z2hTdwaDD1kWt5ZGwlHtI3J8g==
X-Received: by 2002:a17:907:9487:b0:ac1:ed96:56d9 with SMTP id a640c23a62f3a-ac20dd08ec6mr665020866b.40.1741255219081;
        Thu, 06 Mar 2025 02:00:19 -0800 (PST)
Received: from smtpclient.apple (luna-fc1629a6ed0c86150000f.net.as198747.daniil.it. [2a0e:97c0:38f:0:5168:c0de:6a92:61cf])
        by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ac2394858a3sm69169366b.62.2025.03.06.02.00.18
        for <internals@lists.php.net>
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Thu, 06 Mar 2025 02:00:18 -0800 (PST)
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_FEAEF86B-6D18-4C4E-B273-B53164DDF16D"
Precedence: bulk
list-help: <mailto:internals+help@lists.php.net
list-unsubscribe: <mailto:internals+unsubscribe@lists.php.net>
list-post: <mailto:internals@lists.php.net>
List-Id: internals.lists.php.net
x-ms-reactions: disallow
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>
X-Mailer: Apple Mail (2.3826.400.131.1.6)
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--