Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:126599 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 AC1BE1A00BC for ; Thu, 6 Mar 2025 09:58:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1741254978; bh=BYdZfaesG7RaZ5aKEyhSJDBKjZ7oZbFddY9QXICBcGQ=; h=From:Subject:Date:References:To:In-Reply-To:From; b=YwBMOoRTBxwpjIHlPDysIo2rXycGK6cq4ctsVBebo1MddHLVLThCNB8LGtk7z7AgR J9j1odF/GULNHOTSIooooU+UQCMs1gN5aZPnQSU7pP0Y6XSMYjhDuCsQjD7b4+yLXt Ot4eY0ZnpaMLg4zOA9DP9miRGDR/dUkzx/xgzw61rh1qrXILAWPT3E4Lp9Cm7EqMsr LKaOhtg47dgVKaDRA9YitNmOkd7fgdyROXgA31XeCQb9wfsYgjpodyQ1jxIxfiXAz3 iYdQNXiQ6cf+YsIEn80e7DDzgSgQSIg0+jGGg5JW1pxOYQcxJVVJebCl0d9JZcFrkG 4MPnh31NnyOEQ== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id A0813180053 for ; Thu, 6 Mar 2025 09:56:17 +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=-0.1 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_40, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS, HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, SPF_HELO_NONE,SPF_PASS,URIBL_SBL_A autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: No X-Envelope-From: Received: from sender4-of-o52.zoho.com (sender4-of-o52.zoho.com [136.143.188.52]) (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 ; Thu, 6 Mar 2025 09:56:16 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; t=1741255129; cv=none; d=zohomail.com; s=zohoarc; b=ioWLAWdjCJrFkvKGPC+AX8R6TFIUUn79GM9IIq3C2fDKYZhohsRUvE3fTvP8O48oZGFEr9SPuW+/5SXhysVS2xFngWquD43xDzMmTP8/cpb123yyL3ZLUBk/lbhEZfxxOLguvreJpOv+wyrmRSNrNbdjBcRQEAmWWWMEpkIL2VE= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1741255129; h=Content-Type:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To:Cc; bh=LGePgN9Tf12jfgcaj9XCjn+Ux8rBkenR9eGs9T2wCwU=; b=CobM8hcyO3V0HqDX31Pt8WnBjLVs3FKtYpdRiEoXpfLc5as1L+mNWxC4GnftrgABsfMZviZ+j5YdOXL19y0tSYOr3gYOBSjNcq+7w+hWt+74lvd9WeMRtU5J/885E6b1S46zFPckByizf57/UJKAQccmhzSBQepIAhpml9H6v0I= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=daniil.it; spf=pass smtp.mailfrom=daniil@daniil.it; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1741255129; s=daniil; d=daniil.it; i=daniil@daniil.it; h=From:From:Content-Type:Mime-Version:Subject:Subject:Date:Date:References:To:To:In-Reply-To:Message-Id:Message-Id:Reply-To:Cc; bh=LGePgN9Tf12jfgcaj9XCjn+Ux8rBkenR9eGs9T2wCwU=; b=S7jclzE6YP+rWJMPTD6q/SLtaQEh5lFuUZLAk4EsVg40P9TfLm7PGNsPtmLzS1YI dDIUTA+WWW+MubCDfmPZuuuoJmwHxjADhJe6Cg2jycLW4jiP73nccKnGjl40ptjzztH jhKyVIl7Qd941ccrxXkSHA3mXs11ndLR1RDp+tWo= Received: by mx.zohomail.com with SMTPS id 1741255124972671.9487158617478; Thu, 6 Mar 2025 01:58:44 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_8D04F88E-E3FF-41C6-9F65-84A8B68C2B5A" Precedence: bulk list-help: list-post: 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 10:58:32 +0100 References: <9964db8c-0ffe-43d5-8246-47fc76b07180@app.fastmail.com> <78a03dd0-fd4a-4f4a-ad8a-37e5704f06fc@app.fastmail.com> To: internals@lists.php.net In-Reply-To: Message-ID: <54736CFE-DDCB-46A3-88A0-CFED30ED2CAA@daniil.it> X-Mailer: Apple Mail (2.3826.400.131.1.6) X-ZohoMailClient: External From: daniil@daniil.it (Daniil Gentili) --Apple-Mail=_8D04F88E-E3FF-41C6-9F65-84A8B68C2B5A 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 Telegram: https://t.me/danogentili --Apple-Mail=_8D04F88E-E3FF-41C6-9F65-84A8B68C2B5A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; 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 )

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-con= currency-or-go-statement-considered-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.

^ = 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). 

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 

Portfolio: https://daniil.it
= --Apple-Mail=_8D04F88E-E3FF-41C6-9F65-84A8B68C2B5A--