Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:129246 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 5220A1A00BC for ; Sat, 15 Nov 2025 22:01:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1763244095; bh=J6j2RO7gDOc4sT7wpSs7uihPE5jQRJXxFzwB7e7x66c=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=jd8nYfIfUttxhKJ5AQoXO0/eBu8hIqHbVdLf6rSNHYTU57mHx20A8gayEpt9BXe36 pmz9pGcdjiKNNHVyIEdPXxwwnsZywrr6l6db2f41AlAspkkerBbyOAYhoi1j+qZqx3 fW5ZecTVthviTaicwtBpXoBJEcWQsgWKfFJ+AGPTZtHsEOgrnuMqHYbE5RlQFybktz kpOsZ6FPylfAJ2mnbnIUz2OaYXpS2oEFgWYT/RoeGzccfzOoE6f+Hxtjp3WByxn+A9 JVQEyNVL0bD95yEp16Ctjdvwdn/naOoNER3cXB77URlZBNr7v3oX0+ctmaan6QTBrX sanfGizTuKR2g== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id E7E8418053C for ; Sat, 15 Nov 2025 22:01:34 +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 fout-b2-smtp.messagingengine.com (fout-b2-smtp.messagingengine.com [202.12.124.145]) (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 22:01:24 +0000 (UTC) Received: from phl-compute-12.internal (phl-compute-12.internal [10.202.2.52]) by mailfout.stl.internal (Postfix) with ESMTP id 7FBA61D00077; Sat, 15 Nov 2025 17:01:14 -0500 (EST) Received: from phl-imap-05 ([10.202.2.95]) by phl-compute-12.internal (MEProxy); Sat, 15 Nov 2025 17:01:14 -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=1763244074; x= 1763330474; bh=J6j2RO7gDOc4sT7wpSs7uihPE5jQRJXxFzwB7e7x66c=; b=l xGb5fFV6D3AtMktFsdmgtBg8dskz50gkksT2YgWxbM+9AzCG0Qk9rMyS+8VJ1mYX 15EHhohyQ5lQlTbeOVgntd4wtF0OAgGHR4K/NHeYScjkhL/sVZz9zSw/5SFVvud3 n0pTeADeNy1dNinN64znSgQ1sdG2hnibY7jqfa9aPlRYz9eRS1NyxQ+71e0c59DB b3NbWdsALANYG6hZXYWdK+Te5/WiZEcLmsT6cnPW7IgtjGaBTpzvkzeZRSMwECtE go9vIAb114SBXAv7k/UY7cdR6aEpPyFvUD1eZ1+/gBDAaNIVu8eR9EyIruc6wFP5 xQZGqLI4OFUdwDY9opScg== 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= 1763244074; x=1763330474; bh=J6j2RO7gDOc4sT7wpSs7uihPE5jQRJXxFzw B7e7x66c=; b=X+bJDZtYUXvmWluCGngIl+3NNoeYMSytM4p4nOUz0IxTDLI9O+a Mkmor2IictVVoGi8mc3wWOApLR3JtLUn0/9QtOgtg2GZzE4fnsP3wy4XR7DNqxiN FVB0OPklMF7XFZ3GutFDgpoVmQgK9U5gDXxnJOsVa1FEDlKlSrs7ZRwybhZpLR/h +HsB37fR4AbOyaCqqaK9uWThwPa0hH3rcoB98Ynw2SOHqk2lHMNXbK8d0SNT6Hbh Na4MfZGOHuNl3tSA7IJvvFpg5js8VmuWvoshDnPsuiZmsiETAQQH5SkoraM4RezJ 7RwRtUQaMqkfdRDDdbEgozRLbNqb6pn/FpA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggddvudefkeegucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepofggfffhvfevkfgjfhfutgesrgdtreerredtjeenucfhrhhomhepfdftohgsucfn rghnuggvrhhsfdcuoehrohgssegsohhtthhlvggurdgtohguvghsqeenucggtffrrghtth gvrhhnpeejtdelkedtheeuteeffeeguedvledtfeejffejgfehtefhteevveefgfdvvdel vdenucffohhmrghinhephhhtthhpuhhrlhdrrghnnecuvehluhhsthgvrhfuihiivgeptd enucfrrghrrghmpehmrghilhhfrhhomheprhhosgessghothhtlhgvugdrtghouggvshdp nhgspghrtghpthhtohepgedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtoheplhgrrh hrhiesghgrrhhfihgvlhguthgvtghhrdgtohhmpdhrtghpthhtohepvggumhhonhgurdhh thesghhmrghilhdrtghomhdprhgtphhtthhopehinhhtvghrnhgrlhhssehlihhsthhsrd hphhhprdhnvghtpdhrtghpthhtohepsghukhhkrgesphhhphdrnhgvth X-ME-Proxy: Feedback-ID: ifab94697:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id C839D1820054; Sat, 15 Nov 2025 17:01:13 -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 23:00:53 +0100 To: "Jakub Zelenka" Cc: "Edmond Dantes" , "php internals" , "Larry Garfield" Message-ID: In-Reply-To: References: <6618a91c-5393-4f40-88b5-b5041ee09deb@app.fastmail.com> <3e0cf0a1-c1a3-4e05-97ba-0eeb7f559a53@app.fastmail.com> <41c5eed0-dd1b-4ea4-99cf-f6d16682bd7f@app.fastmail.com> Subject: Re: [PHP-DEV] Re: PHP True Async RFC Stage 5 Content-Type: multipart/alternative; boundary=cb5adbe3a68b464c918b7d2ddd8f56f9 From: rob@bottled.codes ("Rob Landers") --cb5adbe3a68b464c918b7d2ddd8f56f9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Sat, Nov 15, 2025, at 22:40, Jakub Zelenka wrote: >=20 >=20 > On Sat, Nov 15, 2025 at 10:19=E2=80=AFPM Rob Landers wrote: >> __ >>=20 >>=20 >> On Sat, Nov 15, 2025, at 22:17, Jakub Zelenka wrote: >>> Hi, >>>=20 >>> On Sat, Nov 15, 2025 at 8:56=E2=80=AFPM Rob Landers wrote: >>>> __ >>>> On Sat, Nov 15, 2025, at 15:41, Edmond Dantes wrote: >>>>> Hello. >>>>>=20 >>>>> > Based on the conversation so far, I=E2=80=99d imagine the list t= o look something like: >>>>>=20 >>>>> Yes, that=E2=80=99s absolutely correct. When a programmer uses an = operation >>>>> that would normally block the entire thread, control is handed ove= r to >>>>> the Scheduler instead. >>>>> The suspend function is called inside all of these operations. >>>>=20 >>>> I think that "normally" is doing a lot of work here. `fwrite()` can= block, but often doesn=E2=80=99t. `file_get_contents()` is usually inst= ant for local files but can take seconds on NFS or with an HTTP URL. An = `array_map()` *always* blocks the thread but should *never* suspend. >>>>=20 >>>> Without very clear rules, it becomes impossible to reason about wha= t=E2=80=99ll suspend and what won=E2=80=99t. >>>>=20 >>>>>=20 >>>>> > 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. >>>>>=20 >>>>> In the Async implementation, it will be specified which functions = are supported. >>>>=20 >>>> This is exactly the kind of thing that needs to be in the RFC itsel= f. Relying on "the implementation will document it" creates an unstable = contract. >>>>=20 >>>> Even something simple like: >>>>=20 >>>> - if it can perform network IO >>>> - if it can perform file/stream IO >>>> - if it can sleep or wait on timers >>>=20 >>> None of the above is part is this RFC so why is this being discussed= . Any of the changes to stream layer and extensions will require special= RFC and mainly clean implementation. We will need to carefully consider= where the suspension is going to be done. >>=20 >> My point is that it *should* be a part of the RFC. >=20 > But this is hard to know exactly. Also there will be always 3rd extens= ions that can block so we will need to do it piece by piece. You can jus= t take it that ideally everything that can block would be suspendable . = The first candidate is surely stream internall poll that is used for str= eam IO in various places and could handles most suspensions including in= mysqlnd. Then curl and sockets would be probably added. There are vario= us other bits already present in Edmonds PoC but we will need to conside= r them one by one. >=20 > In other words, we can't really know that until we have some base piec= es merged (this RFC) and there is acceptable implementation that can be = merged for those parts. >=20 > Kind regards, >=20 > Jakub I guess my main thing is that this RFC should only cover coroutine machi= nery: it should *not* promise "transparent async" or "code that works ex= actly the same" *OR *if it wants to make those claims, it should actuall= y demonstrate *how* instead of hand-waving everything as an "implementat= ion detail" when none of those claims can actually be validated without = those details. =E2=80=94 Rob --cb5adbe3a68b464c918b7d2ddd8f56f9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


On Sat, Nov 15, 2025, at 22:40, Jakub Zelenka wrote:


On Sat, No= v 15, 2025 at 10:19=E2=80=AFPM Rob Landers <rob@bottled.codes> wro= te:



O= n Sat, Nov 15, 2025, at 22:17, Jakub Zelenka wrote:
Hi,

On Sat, Nov 15,= 2025 at 8:56=E2=80=AFPM Rob Landers <rob@bottled.codes> wrote:

=
On Sat, Nov 15, 2025, at 15:41, Edmond Dantes wrote:
Hello.

> Based on the conversat= ion so far, I=E2=80=99d imagine the list to look something like:

Yes, that=E2=80=99s absolutely correct. When a program= mer uses an operation
that would normally block the entire thr= ead, control is handed over to
the Scheduler instead.
The suspend function is called inside all of these operations.

I think that "normally" is doing a lot of= work here. fwrite() can block= , but often doesn=E2=80=99t. file_get= _contents() is usually instant for local files but can take secon= ds on NFS or with an HTTP URL. An arr= ay_map() always blocks the thread but should never = suspend.

Without very clear rules, it becomes i= mpossible to reason about what=E2=80=99ll suspend and what won=E2=80=99t= .


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

In the Async implementa= tion, it will be specified which functions are supported.

This is exactly the kind of thing that needs to = be in the RFC itself. Relying on "the implementation will document it" c= reates an unstable contract.

Even something sim= ple like:

- if it can perform network IO
<= div>- if it can perform file/stream IO
- if it can sleep or wa= it on timers

None of the abo= ve is part is this RFC so why is this being discussed. Any of the change= s to stream layer and extensions will require special RFC and mainly cle= an implementation. We will need to carefully consider where the suspensi= on is going to be done.

My point is that it should be a part of the RFC.

But this is hard to know exactl= y. Also there will be always 3rd extensions that can block so we will ne= ed to do it piece by piece. You can just take it that ideally everything= that can block would be suspendable . The first candidate is surely str= eam internall poll that is used for stream IO in various places and coul= d handles most suspensions including in mysqlnd. Then curl and sockets w= ould be probably added. There are various other bits already present in = Edmonds PoC but we will need to consider them one by one.

=
In other words, we can't really know that until we have some = base pieces merged (this RFC) and there is acceptable implementation tha= t can be merged for those parts.

Kind regards,<= /div>

Jakub

I guess my main thing is that this RFC should only cover corout= ine machinery: it should not promise "transparent async= " or "code that works exactly the same" OR if it wants to make th= ose claims, it should actually demonstrate how instead of ha= nd-waving everything as an "implementation detail" when none of those cl= aims can actually be validated without those details.

=
=E2=80=94 Rob
--cb5adbe3a68b464c918b7d2ddd8f56f9--