Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:128934 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 lists.php.net (Postfix) with ESMTPS id 2F2601A00BC for ; Thu, 23 Oct 2025 16:10:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1761235840; bh=NoVg1dN0zA8miCvpqH3Zkgd1OdNegWJMex/JasRn/hE=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=f8uE/tBsL0pgN2inHi7ZvWBqDiWxjNeJOmU/9qaqbIXf4B2MzWXsQbyE6Myplapck Xlvh0STzRg2O6jzqvjE3fCoI6txqQck6Gle9tqp/V8QKDLEAB70Uqlm8Hjm046tBwU NCWv8RZ25wA39oEJlxbA1j9a/1xNtkNTssLkq99ZT13v+C9odtqcYTRMfPX0wPi39f VnHsXXXSsTEBLawOP84TUfshOnip3V7EM/B2m0x0COp2LN3+vbIhq22+Ou57DIzmPB fUf/5WB1uqCgYnX4I/vyqDob0+OFy+WNsMNp1+SlNSQkjiqfRArzY2owaQCAZsI4ma /My6c+ujgZgoA== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 5294D180083 for ; Thu, 23 Oct 2025 16:10:39 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_20,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_MISSING,HTML_MESSAGE, RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS autolearn=no autolearn_force=no version=4.0.1 X-Spam-Virus: No X-Envelope-From: Received: from fhigh-b5-smtp.messagingengine.com (fhigh-b5-smtp.messagingengine.com [202.12.124.156]) (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, 23 Oct 2025 16:10:38 +0000 (UTC) Received: from phl-compute-05.internal (phl-compute-05.internal [10.202.2.45]) by mailfhigh.stl.internal (Postfix) with ESMTP id 52D337A0101; Thu, 23 Oct 2025 12:10:33 -0400 (EDT) Received: from phl-imap-05 ([10.202.2.95]) by phl-compute-05.internal (MEProxy); Thu, 23 Oct 2025 12:10:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bottled.codes; h=cc: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=fm3; t=1761235833; x= 1761322233; bh=NoVg1dN0zA8miCvpqH3Zkgd1OdNegWJMex/JasRn/hE=; b=r y6uSoZnvkBUUkc8baoE0yQL94LlCGqVG8DpoyTqFDAaLwyEsa96xKfKP2lLRnJ7p 74zS9SxkUuirnlZRzb0QHljxF8fnr75DSWMVr0bsAvvITwpnIvRqi5LB7skrugqw BTNd4Qn2ccgpx4CM9f2uKQKoY/5z8vuqgHneUQYEu1zCf0iQ+BZm064o1g5inpza K5Ac90JBR1nO6NzF429Ks0Lc40RRsdPxNA6WD4dGTpI3W27l/wLTNSNSNt1q36wd TsqEQfPv7Jad4npYxufvVhUQab931Aa0ToRPAg975o+kyYye4FEXWqQJ5P7azv8x 7qfrVvw/1hpmg0KX9UwuQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=fm2; t= 1761235833; x=1761322233; bh=NoVg1dN0zA8miCvpqH3Zkgd1OdNegWJMex/ JasRn/hE=; b=ELWizgiemhsTOVGOw/902ixxuXUjqQragEKAwW+UUnnDWCVbMjx 0wGmMPNNEGruCoXIgdNToFM5K1bY5lJDeJIj0V9M6H1obkul0cCxWP7xoctIGWVF x4kBCebsuqxNC3yuSCJXGyYbQ7dboZticQpMq8q5XeQQjvl7ZRf6KeSGppFOH0/X qtEG2YZJh36/R6rl151nuRljCWBgsitOSEKADxe23Qtd+vNODEfyp7885SYnrgLS O6emTxTP3Uelt0cPrluSA7NZkcW+FuRUjAsOkLHzcxIHClhgt4t06yUpGxY7gCqQ QrBl34kXAwBEfDMXOakq2shhPPfOnL295qg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggddugeeiledtucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepofggfffhvfevkfgjfhfutgesrgdtreerredtjeenucfhrhhomhepfdftohgsucfn rghnuggvrhhsfdcuoehrohgssegsohhtthhlvggurdgtohguvghsqeenucggtffrrghtth gvrhhnpeevfeejudefveeiledtteevjefhieetleelveektdfgvddtieduvdetvdfftdfh udenucffohhmrghinhepshifihhfthdrohhrghdpghhithhhuhgsrdgtohhmpddtfedtge dqshhtrhhutghtuhhrvgguqdgtohhntghurhhrvghntgihrdhmugenucevlhhushhtvghr ufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehrohgssegsohhtthhlvggurd gtohguvghspdhnsggprhgtphhtthhopeegpdhmohguvgepshhmthhpohhuthdprhgtphht thhopegrlhgvtgesrghlvggtrdhplhdprhgtphhtthhopegvughmohhnugdrhhhtsehgmh grihhlrdgtohhmpdhrtghpthhtohepihhnthgvrhhnrghlsheslhhishhtshdrphhhphdr nhgvthdprhgtphhtthhopehjsggrfhhfohhrugesiihorhhtrdhnvght X-ME-Proxy: Feedback-ID: ifab94697:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id ECC861820054; Thu, 23 Oct 2025 12:10:31 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface Precedence: list list-help: list-unsubscribe: list-post: List-Id: x-ms-reactions: disallow MIME-Version: 1.0 X-ThreadId: AQpA1KTaY2GJ Date: Thu, 23 Oct 2025 18:10:11 +0200 To: "John Bafford" , "Edmond Dantes" Cc: "Aleksander Machniak" , "PHP Internals" Message-ID: <79b4e97b-0475-4c9f-ab4d-84ed0d8a8a4d@app.fastmail.com> In-Reply-To: References: <0e4e39d6-9cc9-4970-92e0-2463143b4011@app.fastmail.com> <37180d8d-85b4-49a3-a672-334bf4329470@app.fastmail.com> <2f8524a7-dea2-4fbf-933a-c538d3706253@app.fastmail.com> <151800a7-1094-49bc-8e43-c593a74741af@app.fastmail.com> Subject: Re: [PHP-DEV] PHP True Async RFC Stage 4 Content-Type: multipart/alternative; boundary=95d5c664f7c24bd4b0a0aa3f74fb71ba From: rob@bottled.codes ("Rob Landers") --95d5c664f7c24bd4b0a0aa3f74fb71ba Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Thu, Oct 23, 2025, at 18:01, John Bafford wrote: > Hi, >=20 > > On Oct 23, 2025, at 01:56, Edmond Dantes wrote: > >=20 > > Hi, > >=20 > >> it makes that future RFC's job unnecessary harder > >=20 > > If you want to make PHP multithreaded and plan to change the language > > syntax while avoiding future issues, it would be reasonable to discu= ss > > the changes using specific syntax examples. > > Can you show me the cases you want to implement? >=20 > I don't have any specific use-cases in mind. I'm just trying to be for= ward-looking here. But what is clear is that some people would like to s= ee async/await in PHP. This RFC would ostensibly be a step towards that.= All I'm trying to do is make sure that it doesn't put up roadblocks for= future enhancements. >=20 >=20 > >> I can't find where this `awaitXX` function is defined > > It was in the third version of the RFC. > >=20 > >> So you say "Awaitable objects do not return multiple values. > >=20 > > 1. multiple values: > >=20 > > ```php > > $fs =3D new FileSystemEvents(); > >=20 > > // At that moment, the user created file1 and then file2. > > $event =3D await($fs); > >=20 > > // Now: $event contains [file1, file2] -- The coroutine captured two > > events at once. > > ``` > >=20 > > 2. signe value: > >=20 > > ```php > > $fs =3D new FileSystemEvents(); > >=20 > > // At that moment, the user created file1 and then file2. > > $event =3D await($fs); > >=20 > > // Now: $event contains file1 -- ONLY ONE VALUE! > > ``` > >=20 > >> but to me it feels like you're just dismissing Rob and my concern > > It=E2=80=99s hard three times over, because the expression foreach(a= wait() as > > ) is considered valid only if await returns a value once. >=20 > I think there are two bad designs here. >=20 > First: If you have something that streams results, then the interface = to access should reflect streaming. And it should be an error (preferabl= y thrown at compile time) if you try and treat a stream as a single valu= e, or a single value as a stream. This is whether it's async or not. And= we already have an interface one can implement if one has an iterable s= equence of events, so that you can either call the iteration functions d= irectly, or use foreach() which provides syntactic sugar over that. >=20 > Second: it should be emitting either a stream of files, or a stream of= arrays of files. Returning list|File is not a great pattern. >=20 >=20 > >> btw, if you haven't read through the Swift Evolution proposals for = structured concurrency, > > Thanks for the idea. I haven=E2=80=99t read that discussion. > > Is it https://forums.swift.org/t/se-0304-structured-concurrency/4531= 4 ? >=20 > That's the first review thread for Swift's Structured Concurrency prop= osal. The proposal itself is here, along with links to the three pitch a= nd three review threads, and the async/await and actor proposals: > https://github.com/swiftlang/swift-evolution/blob/main/proposals/0304-= structured-concurrency.md >=20 > (see also the async/await and actors proposals, linked from that propo= sal. Note that a nontrivial portion of the proposal covers actor isolati= on, which is obviously beyond the scope of this RFC, but whether or not = a future multithreading async extension uses actor isolation as its safe= ty concept, those concepts are still generally relevant.) >=20 >=20 >=20 > >> What I'm proposing that specifically Async\protect() and *forcibly*= cancelling coroutines should be removed. > > This RFC does not include forced coroutine termination, only > > cooperative cancellation using exceptions. > > If we remove the protect function, we=E2=80=99ll also have to remove > > cooperative cancellation. >=20 > Why is the protect function needed, then? If you request cancellation,= the coroutine is free to ignore the cancellation and run to completion.= That's what makes it cooperative. I assume it is because you can't control the whole stack. For example, i= f you're calling file_put_contents(), you don't want it to cancel if a c= ancellation is received from outside the coroutine, which might put your= application in a bad state. This goes back to including the reasoning i= n the RFC though, because I can only assume. =E2=80=94 Rob --95d5c664f7c24bd4b0a0aa3f74fb71ba Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


On Thu, Oct 23, 2025, at 18:01, John Bafford wrote:
Hi,
> On Oct 23, 2025, at 01:56, Edmond Dantes <edmond.ht@gmail.com> wrote:
> 
> Hi,
> 
>> = it makes that future RFC's job unnecessary harder
> 
> If you want to make PHP multithreaded and plan to change t= he language
> syntax while avoiding future issues, it would= be reasonable to discuss
> the changes using specific synt= ax examples.
> Can you show me the cases you want to implem= ent?

I don't have any specific use-cases in min= d. I'm just trying to be forward-looking here. But what is clear is that= some people would like to see async/await in PHP. This RFC would ostens= ibly be a step towards that. All I'm trying to do is make sure that it d= oesn't put up roadblocks for future enhancements.


>> I can't find where this `awaitXX` function is= defined
> It was in the third version of the RFC.
> 
>> So you say "Awaitable objects do not ret= urn multiple values.
> 
> 1. multiple val= ues:
> 
> ```php
> $fs =3D n= ew FileSystemEvents();
> 
> // At that mo= ment, the user created file1 and then file2.
> $event =3D a= wait($fs);
> 
> // Now: $event contains [= file1, file2] -- The coroutine captured two
> events at onc= e.
> ```
> 
> 2. signe value= :
> 
> ```php
> $fs =3D new = FileSystemEvents();
> 
> // At that momen= t, the user created file1 and then file2.
> $event =3D awai= t($fs);
> 
> // Now: $event contains file= 1 -- ONLY ONE VALUE!
> ```
> 
&= gt;> but to me it feels like you're just dismissing Rob and my concer= n
> It=E2=80=99s hard three times over, because the express= ion foreach(await() as
> ) is considered valid only if awai= t returns a value once.

I think there are two b= ad designs here.

First: If you have something t= hat streams results, then the interface to access should reflect streami= ng. And it should be an error (preferably thrown at compile time) if you= try and treat a stream as a single value, or a single value as a stream= . This is whether it's async or not. And we already have an interface on= e can implement if one has an iterable sequence of events, so that you c= an either call the iteration functions directly, or use foreach() which = provides syntactic sugar over that.

Second: it = should be emitting either a stream of files, or a stream of arrays of fi= les. Returning list<File>|File is not a great pattern.
<= br>

>> btw, if you haven't read through t= he Swift Evolution proposals for structured concurrency,
> = Thanks for the idea. I haven=E2=80=99t read that discussion.

That's the first review thread= for Swift's Structured Concurrency proposal. The proposal itself is her= e, along with links to the three pitch and three review threads, and the= async/await and actor proposals:

(see also t= he async/await and actors proposals, linked from that proposal. Note tha= t a nontrivial portion of the proposal covers actor isolation, which is = obviously beyond the scope of this RFC, but whether or not a future mult= ithreading async extension uses actor isolation as its safety concept, t= hose concepts are still generally relevant.)


>> What I'm proposing that specificall= y Async\protect() and *forcibly* cancelling coroutines should be removed= .
> This RFC does not include forced coroutine termination,= only
> cooperative cancellation using exceptions.
> If we remove the protect function, we=E2=80=99ll also have to rem= ove
> cooperative cancellation.

Wh= y is the protect function needed, then? If you request cancellation, the= coroutine is free to ignore the cancellation and run to completion. Tha= t's what makes it cooperative.

I a= ssume it is because you can't control the whole stack. For example, if y= ou're calling file_put_contents(), you don't want it to cancel if a canc= ellation is received from outside the coroutine, which might put your ap= plication in a bad state. This goes back to including the reasoning in t= he RFC though, because I can only assume.

=E2=80=94 Rob
--95d5c664f7c24bd4b0a0aa3f74fb71ba--