Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:129231 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 7B7C41A00BC for ; Sat, 15 Nov 2025 14:10:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1763215829; bh=G0k498DFVZYbvdorMPTYTNwDng/kRkZnah+tkcjIGX8=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=DO2pa/j4ZwNwsoTt7TBfNM0ICGSoYVK+z/6VTV3Q92zhagnEi3zwTZONLm6ehZ/Ft HVrtl1aaUm1ROaR6ZkLl4qLwG9F0bFI0ChWUY7qQu/+Z+fQevCxd1MxXrR1/F+NAfd xPGvTEORUzal989HGKJeuWFiP0JD6+YJjv1j1krY4xL3sLZVckqFFhujjrHPTudHUN kmDqcnylLS+nNz4xaehvYSuY+7Q9ByD4KqCvq8rAVArZmGM6bRwTWIUrFq031vZ3Pe qCTRIuXmC05kSKXuZPu0dD225IsC1E4b2y+Hv6/HDLSx2gCaTLnvhLLlH3td654ck7 r8r64/h4u4HkA== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 084FE1801D6 for ; Sat, 15 Nov 2025 14:10:28 +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-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 ; Sat, 15 Nov 2025 14:10:27 +0000 (UTC) Received: from phl-compute-12.internal (phl-compute-12.internal [10.202.2.52]) by mailfhigh.stl.internal (Postfix) with ESMTP id 2BB2F7A00A7; Sat, 15 Nov 2025 09:10:22 -0500 (EST) Received: from phl-imap-05 ([10.202.2.95]) by phl-compute-12.internal (MEProxy); Sat, 15 Nov 2025 09:10:22 -0500 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=fm1; t=1763215822; x= 1763302222; bh=G0k498DFVZYbvdorMPTYTNwDng/kRkZnah+tkcjIGX8=; b=Q gHewPkddGS+eLJnNbihx4U1zu2eLdEYPOQMnC00yf2xx1bForvyuvp1dG8HEseCQ yT9c2njY2T9li8sumCVvbpfaIFkCeq2jt77iSHkeDiVxljqSC/zPAJHc74a/AODb 1ApKKs8Nzpbq9mnOCV0sgSUkP3j89YfiFWSiLI9h/OksFx7mx8HamW/COu3wdBIp yrfoqsIhb+JewfOynTDRQtuWOQ+6UvcG4XVuWPgpF2HNvMcM78mU/xqaFUREt14C RAyF0PIhOCPhFBFe/vLjQabymKsfad/hb5+NrmvkWGF41y8Xhipq0y2ESU4lRWAi 3TvJYuTllmsdL32fA/qtg== 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=fm3; t= 1763215822; x=1763302222; bh=G0k498DFVZYbvdorMPTYTNwDng/kRkZnah+ tkcjIGX8=; b=cpjlzX6RE6r2E+uG/BI4+2FkGPbcmw+Z2FJzMBl7yQ8vMLgpj9w 6SuKZOIZjZo2loqfCfjacTj2qYueb5T/pe2DH7wWAXJn9keophMFKv2CN2+d0t01 wmBew3RAFlgdks1zAbjeAk3qFj9KPPAkc/N/Jwif7Jr5W6JMZ3s0J7zO4JLzzFPO RZ7WelxT+HsjiX4bJjno9tscUygyA6Er4ryPZNbf3H0q4WAIF+mrNl7K4m518TjM sPOEneL+ZKFZgyHu0+03doyDdkqBkHV8aB3zS/j2WkK3HOXVb6u5qU5fzuHG0AT/ vNRM1SjSsCDqeDWiE3Hrea8hr8ePb56x64Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggddvuddvledtucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepofggfffhvfevkfgjfhfutgesrgdtreerredtjeenucfhrhhomhepfdftohgsucfn rghnuggvrhhsfdcuoehrohgssegsohhtthhlvggurdgtohguvghsqeenucggtffrrghtth gvrhhnpeeiueethedvvdefjefhgfeiheelheehtdfhfeekjefflefgvedvkeduteejjedt tdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehroh gssegsohhtthhlvggurdgtohguvghspdhnsggprhgtphhtthhopeegpdhmohguvgepshhm thhpohhuthdprhgtphhtthhopehlrghrrhihsehgrghrfhhivghlughtvggthhdrtghomh dprhgtphhtthhopegvughmohhnugdrhhhtsehgmhgrihhlrdgtohhmpdhrtghpthhtohep ihhnthgvrhhnrghlsheslhhishhtshdrphhhphdrnhgvthdprhgtphhtthhopegsuhhkkh grsehphhhprdhnvght X-ME-Proxy: Feedback-ID: ifab94697:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 648C61820054; Sat, 15 Nov 2025 09:10:21 -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 15:09:51 +0100 To: "Edmond Dantes" Cc: "php internals" , "Jakub Zelenka" , "Larry Garfield" Message-ID: <3e0cf0a1-c1a3-4e05-97ba-0eeb7f559a53@app.fastmail.com> In-Reply-To: References: <6618a91c-5393-4f40-88b5-b5041ee09deb@app.fastmail.com> Subject: Re: [PHP-DEV] Re: PHP True Async RFC Stage 5 Content-Type: multipart/alternative; boundary=ee1cfce7622a4d9485913539baeb8b45 From: rob@bottled.codes ("Rob Landers") --ee1cfce7622a4d9485913539baeb8b45 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Sat, Nov 15, 2025, at 13:16, Edmond Dantes wrote: > Hello all. >=20 > Some of these questions sound familiar. Let=E2=80=99s try to sort them= out. >=20 > > If I have a tight loop processing data in memory (no I/O), will it m= onopolise the coroutine scheduler? Do I need to manually insert suspend(= ) calls? How do I know when and where? >=20 > A coroutine must yield control on its own. If it keeps it through an > endless loop, then it will be the only one running. >=20 > > The RFC suggests that existing PHP functions won=E2=80=99t automatic= ally be non-blocking. So which will? Is there a way to identify suspensi= on points at the language/API level? >=20 > The RFC does not say that. PHP I/O functions automatically become > non-blocking relative to the whole process. In other words, an I/O > function calls suspend() on its own when needed. The programmer writes > code exactly as before, under the illusion that operations are > executed one after another. >=20 > > Performance implications: Without knowing where suspensions occur, h= ow do developers avoid either: >=20 > In most cases, this is not the developer=E2=80=99s concern. Situations= where > performance is critical should be handled with dedicated tools. > A PHP developer should not have to drop down to the C level. Properly > designed abstractions must provide the required performance. >=20 > I can already anticipate the question: but a developer could write > something like =E2=80=9Cfor i < 10000 suspend=E2=80=9D or something si= milar. > The answer is this: a developer must know how to use abstractions. As > always. Everywhere. In any area of programming. > It=E2=80=99s just as important as respecting proper layering in code. >=20 > Provided that PHP does not try to play the role of a C-level language > (there have already been such attempts, and they keep resurfacing), > and does not try to play a web server or a database system. > For most web scenarios, the current approach is more than sufficient. > This has been proven by Swoole, which has been on the market for many > years. Therefore, performance questions are outside the scope of this > RFC. >=20 > As for the concurrency model, let me remind you that Go has true > multitasking. Goroutines in Go, although they have a =E2=80=9Csyntheti= c=E2=80=9D > stack. But you already know all this well. > This RFC and its implementation describe coroutines in a single > thread. That is very far from what Go provides. >=20 > There is no preemptive multitasking in this RFC because it is > completely unrelated. > This RFC and its implementation provide cooperative concurrency in a > single thread, where coroutine code yields control on its own. > Why was this model chosen? The simple answer is: because it is the > only one that can realistically be implemented within a finite > timeframe. >=20 > Any more questions? >=20 > -- Ed Hey Ed, I feel like we=E2=80=99re talking past each other a bit. I=E2=80=99m not= questioning the choice of a cooperative scheduler, that=E2=80=99s total= ly fine, I=E2=80=99m trying to understand what the actual suspension poi= nts are. Every other language/runtime with cooperative concurrency spell= s this out, because without it developers can=E2=80=99t reason about per= formance or why a deadlock is happening. Based on the conversation so far, I=E2=80=99d imagine the list to look s= omething like: - network i/o (streams/sockets/dns/curl/etc) - sleeps - subprocess waits? `proc_open` and friends? - extensions with a reactor implementation - awaiting `FutureLike` - `suspend()` If that=E2=80=99s the intended model, it=E2=80=99d help to have that spe= lled out directly; it makes it immediately clear which functions can or = will suspend and prevents surprises. I also think the RFC needs at least minimal wording about scheduler guar= antees, even if the details are implementation-specific. For example, is= the scheduler run-to-suspend? FIFO or round-robin wakeup? And non-preem= ptive behaviour only appears here in the thread. It isn=E2=80=99t mentio= ned in the RFC itself. That=E2=80=99s important for people writing long,= CPU-bound loops, since nothing will interrupt them unless they explicit= ly yield. Lastly, cancellation during a syscall is still unclear. If a coroutine i= s cancelled while something like `fwrite()` or a DB write is in progress= , what should happen? Does `fwrite()` still return the number of bytes w= ritten? Does it throw? For write-operations in particular, this affects = whether applications can maintain a consistent state. Clarifying these points would really help people understand how to reaso= n about concurrency with this API. =E2=80=94 Rob --ee1cfce7622a4d9485913539baeb8b45 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Sat, Nov = 15, 2025, at 13:16, Edmond Dantes wrote:
Hello all.

Some of th= ese questions sound familiar. Let=E2=80=99s try to sort them out.
<= div>
> If I have a tight loop processing data in memory= (no I/O), will it monopolise the coroutine scheduler? Do I need to manu= ally insert suspend() calls? How do I know when and where?
A coroutine must yield control on its own. If it keeps it th= rough an
endless loop, then it will be the only one running.

> The RFC suggests that existing PHP function= s won=E2=80=99t automatically be non-blocking. So which will? Is there a= way to identify suspension points at the language/API level?
=
The RFC does not say that. PHP I/O functions automaticall= y become
non-blocking relative to the whole process. In other = words, an I/O
function calls suspend() on its own when needed.= The programmer writes
code exactly as before, under the illus= ion that operations are
executed one after another.
=
> Performance implications: Without knowing where susp= ensions occur, how do developers avoid either:

= In most cases, this is not the developer=E2=80=99s concern. Situations w= here
performance is critical should be handled with dedicated = tools.
A PHP developer should not have to drop down to the C l= evel. Properly
designed abstractions must provide the required= performance.

I can already anticipate the ques= tion: but a developer could write
something like =E2=80=9Cfor = i < 10000 suspend=E2=80=9D or something similar.
The answer= is this: a developer must know how to use abstractions. As
al= ways. Everywhere. In any area of programming.
It=E2=80=99s jus= t as important as respecting proper layering in code.

Provided that PHP does not try to play the role of a C-level lang= uage
(there have already been such attempts, and they keep res= urfacing),
and does not try to play a web server or a database= system.
For most web scenarios, the current approach is more = than sufficient.
This has been proven by Swoole, which has bee= n on the market for many
years. Therefore, performance questio= ns are outside the scope of this
RFC.

As for the concurrency model, let me remind you that Go has true
<= div>multitasking. Goroutines in Go, although they have a =E2=80=9Csynthe= tic=E2=80=9D
stack. But you already know all this well.
<= div>This RFC and its implementation describe coroutines in a single
thread. That is very far from what Go provides.

There is no preemptive multitasking in this RFC because it is
completely unrelated.
This RFC and its implementation p= rovide cooperative concurrency in a
single thread, where corou= tine code yields control on its own.
Why was this model chosen= ? The simple answer is: because it is the
only one that can re= alistically be implemented within a finite
timeframe.

Any more questions?

-- Ed

Hey Ed,

I fee= l like we=E2=80=99re talking past each other a bit. I=E2=80=99m not ques= tioning the choice of a cooperative scheduler, that=E2=80=99s totally fi= ne, I=E2=80=99m trying to understand what the actual suspension points a= re. Every other language/runtime with cooperative concurrency spells thi= s out, because without it developers can=E2=80=99t reason about performa= nce or why a deadlock is happening.

Based on th= e conversation so far, I=E2=80=99d imagine the list to look something li= ke:

- network i/o (streams/sockets/dns/curl/etc= )
- sleeps
- subprocess waits? proc_open and friends?
- exte= nsions with a reactor implementation
- awaiting FutureLike
- suspend()

If that=E2=80=99s the intended model, it=E2=80=99d help to have = that spelled out directly; it makes it immediately clear which functions= can or will suspend and prevents surprises.

I = also think the RFC needs at least minimal wording about scheduler guaran= tees, even if the details are implementation-specific. For example, is t= he scheduler run-to-suspend? FIFO or round-robin wakeup? And non-preempt= ive behaviour only appears here in the thread. It isn=E2=80=99t mentione= d in the RFC itself. That=E2=80=99s important for people writing long, C= PU-bound loops, since nothing will interrupt them unless they explicitly= yield.

Lastly, cancellation during a syscall i= s still unclear. If a coroutine is cancelled while something like fwrite() or a DB write i= s in progress, what should happen? Does fwrite() still return the number of bytes written?= Does it throw? For write-operations in particular, this affects whether= applications can maintain a consistent state.

= Clarifying these points would really help people understand how to reaso= n about concurrency with this API.

=E2=80=94 Rob
--ee1cfce7622a4d9485913539baeb8b45--