Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:126833 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 A43001A00BC for ; Wed, 19 Mar 2025 00:28:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1742343987; bh=5iGqorhMugQzCQS9IUt5Ciz5pJhJy38XBSGKwtJFxL8=; h=Date:From:To:In-Reply-To:References:Subject:From; b=kyTCcfbfdErjg3nCuTN9abaN+F0+T+V+YV3sf+9rvKgb9LRR8c0Rj1bWNS5f7Suhv pLGcBFbyiRA+0TJY2t/Qr4i8Yxk+ef+UM7OYbXKyD7xnF5etGJ8/zlVFSNi8LABKlo 6z+zfU+hCwssCxYgUGnK86mqzpGlN/DNunh2RQrea6Me4GdFsisMkyVk73MbDNQ4SO QRd9Dw+gPzlswJ7QKAMiAaW9jZ9Jl9YPCbB+IuzFmOQBBa5O5te/thvWTpR4y4W3FH 0Lrx93DncoD9hIhR2wF5hAX82WFMRXTiXtcBrRITCu8yzK7myuwSEzrtjC6L9Oe4KB OMR7mfw6tma7A== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 60B3418007F for ; Wed, 19 Mar 2025 00:26:26 +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=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_MISSING,HTML_MESSAGE, RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS, SPF_PASS autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: No X-Envelope-From: Received: from fout-a8-smtp.messagingengine.com (fout-a8-smtp.messagingengine.com [103.168.172.151]) (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 ; Wed, 19 Mar 2025 00:26:26 +0000 (UTC) Received: from phl-compute-11.internal (phl-compute-11.phl.internal [10.202.2.51]) by mailfout.phl.internal (Postfix) with ESMTP id D11A21383407 for ; Tue, 18 Mar 2025 20:28:56 -0400 (EDT) Received: from phl-imap-09 ([10.202.2.99]) by phl-compute-11.internal (MEProxy); Tue, 18 Mar 2025 20:28:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bottled.codes; h=cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm2; t=1742344136; x=1742430536; bh=6BOrt3V3WJ tXBT1hFvJ6SfqTPO6ldwwciNhdlhFjftU=; b=bpntriuFqHQ8W6I5b12pSvfKP4 QGQ/H6A7wrOGJuQqvkudG8PMrHD0uzujw8n+hd1r1p9w0yFBB1/2A9S4eMYLEvRX 6UvlEHz6rajVV5JjMZwx4Vgr/f0gSlnSGdAVIkS7ru9PpdeIPc7eve0sAHjpPDhC +0DkiZ9BiRHVfl4Y0/2MnsXNrSFwilfvJRKx65l23b1B+ho5H9LKLNkWY129jWJr 8YLj4Itev/XIBKZ6T8dSr6PHVHf9bmOCKR5sZANXCMpmN9R9tfB/8q7Uqk2q+CNV sRT8VKnpIE//SQzSzxBXjAUWXXHPX56bwPK/qFxyWNpJN8VW1rE0gVFXzlEw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1742344136; x=1742430536; bh=6BOrt3V3WJtXBT1hFvJ6SfqTPO6ldwwciNh dlhFjftU=; b=MPKwOER8rdHJKWhylMeV62lrPyO35eLSbRFSsNTv9SeNGUA4ecW UpzaBQz+Qg3Xc/8UheqoxHZ1cKJb8gOh0t3C4rmINs4MmGbb3OZOIlnX7pirMYCE GL05BXj6bFdd01rKTDH09jg8uf9fSiyMUMrsIcskGVIhhn7nM9r8LUqi0YWPl+zY azBaIzA/3Etf24peOmGqbi4U9aqLNJJxT3861bwNluiUqCxYVQkgA9KI6VkWVnEn JXRnwKpuWtN71OGrYfcXbqdelsPdjpVu9s1cJl8ykJCPUqMcyORQ4/1XcTQXDOwb zDiJlbtBJ7lQY+YLkU33i6ATnXETK44Lm6Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgddugeefkeelucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucenucfjughrpefogg ffhffvkfgjfhfutgesrgdtreerredtjeenucfhrhhomhepfdftohgsucfnrghnuggvrhhs fdcuoehrohgssegsohhtthhlvggurdgtohguvghsqeenucggtffrrghtthgvrhhnpeelke ehtdfgfefhleeilefggeeihfekvdelfeejtdfflefhheehfffgudetuddutdenucffohhm rghinhepphhhphdrnhgvthenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmh grihhlfhhrohhmpehrohgssegsohhtthhlvggurdgtohguvghspdhnsggprhgtphhtthho pedupdhmohguvgepshhmthhpohhuthdprhgtphhtthhopehinhhtvghrnhgrlhhssehlih hsthhsrdhphhhprdhnvght X-ME-Proxy: Feedback-ID: ifab94697:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 6E5FC780069; Tue, 18 Mar 2025 20:28:56 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net x-ms-reactions: disallow MIME-Version: 1.0 X-ThreadId: Tddbc4133e529e9e0 Date: Wed, 19 Mar 2025 01:28:32 +0100 To: internals@lists.php.net Message-ID: <258a9a97-7c86-44dd-94bf-a397a84300aa@app.fastmail.com> In-Reply-To: References: Subject: Re: [PHP-DEV] PHP True Async RFC - Stage 2 Content-Type: multipart/alternative; boundary=971adf9eae7140518139ce8c62336126 From: rob@bottled.codes ("Rob Landers") --971adf9eae7140518139ce8c62336126 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Sun, Mar 16, 2025, at 10:24, Edmond Dantes wrote: > Good day, everyone. I hope you're doing well. >=20 > https://wiki.php.net/rfc/true_async >=20 > Here is a new version of the RFC dedicated to asynchrony. >=20 > Key differences from the previous version: >=20 > * The RFC is not based on Fiber; it introduces a separate class repres= entation for the asynchronous context. > * All low-level elements, including the Scheduler and Reactor, have be= en removed from the RFC. > * The RFC does not include Future, Channel, or any other primitives, e= xcept those directly related to the implementation of structured concurr= ency. >=20 > The new RFC proposes more significant changes than the previous one; h= owever, all of them are feasible for implementation. >=20 > I have also added PHP code examples to illustrate how it could look wi= thin the API of this RFC. >=20 > I would like to make a few comments right away. In the end, the Kotlin= model lost, and the RFC includes an analysis of why this happened. The = model that won is based on the Actor approach, although, in reality, the= re are no Actors, nor is there an assumption of implementing encapsulate= d processes. >=20 > On an emotional level, the chosen model prevailed because it forces de= velopers to constantly think about how long coroutines will run and what= they should be synchronized with. This somewhat reminded me of Rust=E2=80= =99s approach to lifetime management. >=20 > Another advantage I liked is that there is no need for complex syntax = like in Kotlin, nor do we have to create separate entities like Supervis= ors and so on. Everything is achieved through a simple API that is quite= intuitive. >=20 > Of course, there are also downsides =E2=80=94 how could there not be? = But considering that PHP is a language for web server applications, thes= e trade-offs are acceptable. >=20 > I would like to once again thank everyone who participated in the prev= ious discussion. It was great! =20 Hey Edmond, Here are my notes: > The *Scheduler* and *Reactor* components should be described in a sepa= rate *RFC*, which should focus on the low-level implementation in *C* an= d define *API* contracts for PHP extensions. Generally, RFCs are for changes in the language itself, not for API cont= racts in C. That can generally be handled in PRs, if I understand correc= tly. > The `suspend` function has no parameters and does not return any value= s, unlike the yield operator. If it can throw, then it does return values? I can foresee people abusin= g this for flow control and passing out (serialized) values of suspended= coroutines. Especially if it is broadcast to all other coroutines await= ing it. It is probably simpler to simply allow passing a value out via s= uspend. > The `suspend` function can be used in any function and in any place in= cluding from the main execution flow: Does this mean it is an expression? So you can basically do: return suspend(); $x =3D [suspend(), suspend(), suspend()]; foreach ($x as $_) {} or other weird shenanigans? I think it would be better as a statement. > The `await` function/operator is used to wait for the completion of an= other coroutine: What happens if it throws? Why does it return NULL; why not `void` or th= e result of the awaited spawn? > The `register_shutdown_function` handler operates in synchronous mode,= after asynchronous handlers have already been destroyed. Therefore, the= `register_shutdown_function` code should not use the concurrency API. T= he `suspend()` function will have no effect, and the `spawn` operation w= ill not be executed at all. Wouldn't it be better to throw an exception instead of silently failing? From this section, I really don't like the dual-syntax of `spawn`, it is= function-like, except not. In other words, this won't behave like you w= ould expect it to: spawn ($is_callable ? $callable : $default_callable)($value); I'm not sure what will actually happen here. --- When comparing the three different models, it would be ideal to keep to = the same example for all three and describe how their execution differs = between the example. Having to parse through the examples of each descri= ption is a pain. > Child coroutines inherit the parent's Scope: Hmm. Do you mean this literally? So if I call a random function via spaw= n, it will have access to my current scope? function foo() { $x =3D 'bar'; } $x =3D 'baz'; $scope->spawn(foo(...)); echo $x; // baz or bar?? That seems like a massive footgun. I think you mean to say that it would= behave like normal. If you spawn a function, it behaves like a function= , if you spawn a closure, it closes over variables just like normal. Tho= ugh I think it is worth defining "when" it closes over the variables -- = when it executes the closure, or when it hits the spawn. Does "spawn" not provide a \Scope? --- I still don't understand the need for a special context thing. One of th= e most subtle footguns with go contexts is to propagate the context when= it shouldn't be propagated. For example, if you are sending a value to = a queue, you probably don't want to send the request context. If you did= and the request was cancelled (or even just completed!), it would also = cancel putting the value on the queue -- which is almost certainly what = you do *not* want. Since the context is handled for you, you also have t= o worry about a context disappearing while you are using it, from the lo= oks of things. This can be easily built in userland, so I'm not sure why we are definin= g it as part of the language. > To ensure data encapsulation between different components, *Coroutine = Scope Slots* provide the ability to associate data using *key objects*. = An object instance is unique across the entire application, so code that= does not have access to the object cannot read the data associated with= it. heh, reminds me of records. --- I know I have been critical in this email, but I actually like it; for t= he most part. I think there are still some rough edges to sand down and = polish, but it is on the right track! =E2=80=94 Rob --971adf9eae7140518139ce8c62336126 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable