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 <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> 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 <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 <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 <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). </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 </div><div><br>Portfolio: <a = href=3D"https://daniil.it/">https://daniil.it</a></div><div>Telegram: = ;<a = href=3D"https://t.me/danogentili">https://t.me/danogentili</a></div></div>= </div></body></html>= --Apple-Mail=_FEAEF86B-6D18-4C4E-B273-B53164DDF16D--