Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:129228 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 6F8611A00BC for ; Sat, 15 Nov 2025 11:38:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1763206698; bh=LCi1yNCAMh5rlbil+yEFmEj5IKRcI696wYdYO5bDvdQ=; h=Date:From:To:In-Reply-To:References:Subject:From; b=TXmo3+OwQnbhfPND0YbUtB3uBIRy634ynYsCB8jXheQgj5rnnLLppd427b/NWrS1d RgwwOZUVIayDFztXqYFicf7ecdN89sLiZSg5Na6WNHmgdDl5/3Og8rs70/y+K4DD0h pSHFw1NQ6LcGTxguOR7a3Wwmkvz+OyDILondytK6jBeYoQGh/gJ82zo+NoLy09bUCj 1fTtqfJ+JTUV2ZuTgp+eAYYp0ZIn+qnCoi2l0Q5JcJ3qUDtEkNeZww1ZRMNYyYHRKo 1Q/wkbdDSV5le4q33yc7rcisNxwkegb4RzSM8SzidywIv6C3BcMM+Zg1/bxInNodZg mg9dOhWbqaSYg== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 450CF180057 for ; Sat, 15 Nov 2025 11:38:18 +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.1 required=5.0 tests=BAYES_50,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-b4-smtp.messagingengine.com (fhigh-b4-smtp.messagingengine.com [202.12.124.155]) (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 ; Sat, 15 Nov 2025 11:38:18 +0000 (UTC) Received: from phl-compute-12.internal (phl-compute-12.internal [10.202.2.52]) by mailfhigh.stl.internal (Postfix) with ESMTP id C5DC57A015E; Sat, 15 Nov 2025 06:38:07 -0500 (EST) Received: from phl-imap-05 ([10.202.2.95]) by phl-compute-12.internal (MEProxy); Sat, 15 Nov 2025 06:38:07 -0500 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=fm1; t=1763206687; x=1763293087; bh=+K4Lp2mIkq 9Ckyl8TIP0GfMS3+AbB90Yfam+HT6iXac=; b=q+aB4Nt+CSppBCGaUq4bJRbKju AEh5M3aUEQvYUvgiEwL9k0/r50KQ79WRlug3b2TRXHeWKjfA5/VVdydYNHr0rIdg MKcX4vwPdrkp0flT1oQw33tJgHA2o8P9XErf8MF3tCzQRdqh/VVkZlyadGFIaH8r G3BmAthRPwtUNgqU8P634mmX3ZJHOKUM9CYAzlLOLp2P7JVGzTgVPoofzHrKYf4m CjGkjzAZlHc5lbJOnxHhjlpnew38cv8BxUZngEm0n0Zh7bp56CEJMOyO2SDNNpYB 4I/UoGtdRrpwPtlHCE3B8Nl/F0xaLfs/DZ+THCE+yE/WvmaAjpm8cjb2+Lhw== 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=fm3; t= 1763206687; x=1763293087; bh=+K4Lp2mIkq9Ckyl8TIP0GfMS3+AbB90Yfam +HT6iXac=; b=X8dZoMQ4uYCxa1mBLfK7UrmCi6HhIRVPcvqRWbMFvbqGgQ5you7 YsUlUNSAZlCjj+I7gSvSsRfsEzTnG0ikmYIpI/IwT81GXc0g4K5jeUI9RXwYqnry tZn0usVJ+nacLraYN/sbmnN2DZu5W3cRaORwxsB9B5rCwkc6m6bHu9SnbtgJtYVk GqRmBNQ26TFiFdFmiH9Ho3jg1O5lsLYCUGz8P7OZhZ6cKAAaoxMW3e6xZZohdt72 ckSqh1VpG1luAM1wZi8aag/Fx2/NmOJqW57JpHhR6HKizkRhovkjs39G1BQm4na7 xIqy8ZsMV7LK7ZMsGiiPIwWNHqEElRZxCXQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggddvuddvheelucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepofggfffhvffkjghfufgtsegrtderreertdejnecuhfhrohhmpedftfhosgcunfgr nhguvghrshdfuceorhhosgessghothhtlhgvugdrtghouggvsheqnecuggftrfgrthhtvg hrnheptdeujedttefhueelhfdtleeiudetlefftdduleehffegtdeihefhleeijefgveeg necuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprhhosg essghothhtlhgvugdrtghouggvshdpnhgspghrtghpthhtohepgedpmhhouggvpehsmhht phhouhhtpdhrtghpthhtoheplhgrrhhrhiesghgrrhhfihgvlhguthgvtghhrdgtohhmpd hrtghpthhtohepvggumhhonhgurdhhthesghhmrghilhdrtghomhdprhgtphhtthhopehi nhhtvghrnhgrlhhssehlihhsthhsrdhphhhprdhnvghtpdhrtghpthhtohepsghukhhkrg esphhhphdrnhgvth X-ME-Proxy: Feedback-ID: ifab94697:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id D1C7C182007A; Sat, 15 Nov 2025 06:38:06 -0500 (EST) 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: A2k3WxiDp57Z Date: Sat, 15 Nov 2025 12:37:45 +0100 To: "Edmond Dantes" , "php internals" , "Jakub Zelenka" , "Larry Garfield" Message-ID: <6618a91c-5393-4f40-88b5-b5041ee09deb@app.fastmail.com> In-Reply-To: References: Subject: Re: [PHP-DEV] Re: PHP True Async RFC Stage 5 Content-Type: multipart/alternative; boundary=bc30f08022b740c6aa4da728aac21eca From: rob@bottled.codes ("Rob Landers") --bc30f08022b740c6aa4da728aac21eca Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Thu, Nov 13, 2025, at 10:01, Edmond Dantes wrote: > Hello all. >=20 > Today marks two weeks since the RFC was published. >=20 > I need to apply a few minor fixes that Luis pointed out. >=20 > If anyone else is working on comments for the RFC, please let me know. > If there are no objections, we can start the vote on Monday. >=20 > Best regards, Ed I have concerns about the clarity of when suspension occurs in this RFC. The RFC states as a core goal: "Code that was originally written and intended to run outside of a Corou= tine must work EXACTLY THE SAME inside a Coroutine without modifications= ." And: "A PHP developer should not have to think about how Coroutine switch and= should not need to manage their switching=E2=80=94except in special cas= es where they consciously choose to intervene in this logic." However, the RFC doesn=E2=80=99t clearly define what these "special case= s" are or provide guidance on when developers need to intervene. Specific questions: 1. CPU-bound operations: If I have a tight loop processing data in memor= y (no I/O), will it monopolise the coroutine scheduler? Do I need to man= ually insert `suspend()` calls? How do I know when and where? 2. The RFC suggests that existing PHP functions won=E2=80=99t automatica= lly be non-blocking. So which will? Is there a way to identify suspensio= n points at the language/API level? 3. Performance implications: Without knowing where suspensions occur, ho= w do developers avoid either: - Starving other coroutines (too few suspensions) - Degrading performance (too many suspensions) With explicit async/await ("coloured functions"), developers know exactl= y where suspension can occur. This RFC=E2=80=99s implicit model seems co= nvenient, but without clear rules about suspension points, I=E2=80=99m u= nclear how developers can write correct concurrent code or reason about = performance. Could the RFC clarify the rules for when automatic suspension occurs ver= sus when manual `suspend()` calls are required? Is this RFC following Go= =E2=80=99s model where suspension timing is an implementation detail dev= elopers shouldn=E2=80=99t rely on? If so, that should be stated explicit= ly. Keep in mind that Go didn=E2=80=99t start that way and took nearly a= decade to get there. Earlier versions of Go explicitly stated where sus= pensions were. =E2=80=94 Rob --bc30f08022b740c6aa4da728aac21eca Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Thu, Nov = 13, 2025, at 10:01, Edmond Dantes wrote:
Hello all.

Today mark= s two weeks since the RFC was published.

I need= to apply a few minor fixes that Luis pointed out.

<= div>If anyone else is working on comments for the RFC, please let me kno= w.
If there are no objections, we can start the vote on Monday= .

Best regards, Ed

<= /div>
I have concerns about the clarity of when suspension occurs in= this RFC.

The RFC states as a core goal:
=

"Code that was originally written and intended to ru= n outside of a Coroutine must work EXACTLY THE SAME inside a Coroutine w= ithout modifications."

And:

"A PHP developer should not have to think about how Coroutine swit= ch and should not need to manage their switching=E2=80=94except in speci= al cases where they consciously choose to intervene in this logic."

However, the RFC doesn=E2=80=99t clearly define wha= t these "special cases" are or provide guidance on when developers need = to intervene.

Specific questions:
1. CPU-bound operations: If I have a tight loop processing d= ata in memory (no I/O), will it monopolise the coroutine scheduler? Do I= need to manually insert = suspend() calls? How do I know when and where?
2. T= he RFC suggests that existing PHP functions won=E2=80=99t automatically = be non-blocking. So which will? Is there a way to identify suspension po= ints at the language/API level?
3. Performance implications: W= ithout knowing where suspensions occur, how do developers avoid either:<= /div>
  - Starving other coroutines (too few suspensions)
=
  - Degrading performance (too many suspensions)
With explicit async/await ("coloured functions"), developers= know exactly where suspension can occur. This RFC=E2=80=99s implicit mo= del seems convenient, but without clear rules about suspension points, I= =E2=80=99m unclear how developers can write correct concurrent code or r= eason about performance.

Could the RFC clarify = the rules for when automatic suspension occurs versus when manual suspend() calls are requ= ired? Is this RFC following Go=E2=80=99s model where suspension tim= ing is an implementation detail developers shouldn=E2=80=99t rely on? If= so, that should be stated explicitly. Keep in mind that Go didn=E2=80=99= t start that way and took nearly a decade to get there. Earlier versions= of Go explicitly stated where suspensions were.

=E2=80=94 Rob
--bc30f08022b740c6aa4da728aac21eca--