Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:129244 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 5A3931A00BC for ; Sat, 15 Nov 2025 21:40:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1763242840; bh=lcBKOnXc2iCLacJp3V0X+6jZVaw+dFVjFiFVoEd8l2A=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=YkSw8DVr/2BuNpA4u30/oA9nP4iAjP4v3JgX368IIYjzZFuy6yUMdVPCQ/oI3icG0 2lviho7feeOLg6V93PyIJhXOK1hU824IpftOdgp0Ws5TFbMEidljrCFQGIfbpRAnQV lGv/OCIkJgRC+z8oXTrG5DR0roZfDtj8QJrE2C7URbbiJEcubHFRwNvChufyfdWtWQ HkqWKDFwbw2xqlX/ex22hmUiYIPolhD/y3j5S2UR3OWErdgFZG2DXHfuQDu0P+gqPR p6XDEvldv7Qu5UDEb7S1lj9bTDFJnZXpkC74itPCPUYorpid9zEB3cLvwDbaSeBiIu I1nuZ9cbKSZcg== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id D0C6418033A for ; Sat, 15 Nov 2025 21:40:36 +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=1.8 required=5.0 tests=BAYES_50,DMARC_NONE, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, SPF_HELO_NONE,T_SPF_TEMPERROR autolearn=no autolearn_force=no version=4.0.1 X-Spam-Virus: No X-Envelope-From: Received: from mail-oa1-f45.google.com (mail-oa1-f45.google.com [209.85.160.45]) (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 21:40:36 +0000 (UTC) Received: by mail-oa1-f45.google.com with SMTP id 586e51a60fabf-3e7e94890b3so1621691fac.1 for ; Sat, 15 Nov 2025 13:40:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763242831; x=1763847631; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=lcBKOnXc2iCLacJp3V0X+6jZVaw+dFVjFiFVoEd8l2A=; b=LT7b3AHZjj2heRh7EbO2pt8dYDF+a2EQ5H7w33O4Ao4xqDqhUVROH9WObRwTen9bez hfUl1CbDQRodAfzZqbCwC2EcGHrAwXwinH2Sj1jhRUre3d+r5XT9It1Mxl/Bd5yUvCWL qm+3xvwqldyUDmF3ojKuEXPChfQEjs+2i4U6gbHNYz1FNcm+JkA43/nNCLPuh7vpMBJS LudYDZZCZf7429m7Suwdd0ageBcVa6nyxQM8eonYneYBD2swcEMoL8L95J9t+uQDtqcc tZfWWBOtRgz+oxIjveCh9PgA/o7/HdyvdeOFSt/GCICGV7YTsKvnzEFbaA2SFBrJLeQO OuhQ== X-Forwarded-Encrypted: i=1; AJvYcCXgyfpUBhPfgtPFlhS7uIkMc8Jhirc2sHkbAPVnqDmSbCe0m1Btab0WzPYltUm5EybSopVHIAIcnWw=@lists.php.net X-Gm-Message-State: AOJu0Ywmekj7G0mkCJAjBKJNWjEiTlyEBmvjq6cRqmPyuarXtabeERTH mBF66lI7hWI09lGbkQgr0VneTSEFoX8W93Ao1i7VafMQUdLnZ/iLBEyd0+FkjHN6V6hwsYZgiS4 2ICKV7rfZukZQ1iWUGBZoOqTbHwHen1s= X-Gm-Gg: ASbGnctegfc1V5LhdI6osyNNkQ7eah3CyySPwolVeyEAsw6pmvtJdbnlzO24pjgFe93 EzMTpMdYs89Io+yiFHOJ1PIF3ER+XI36mBylB6Ar0M2j5r9gI/ReCunz7dPotO9w96Hf3gBaTdL oFrLh5JAVPxyBEYmLS4OSzcwNKTwteSCdPoU/+p3HuSxfVj930lyJiQtKLZsS7yNBgQKK1VuTua i4Qxv3EpZ5m1MS+ZwvdHIxzQtF3CNAMmdFGwa6xdytVPhvzlYjGr7ekMx3znmy5Rz5rQPp30jtk smcr X-Google-Smtp-Source: AGHT+IGEPIWaIfTs3GE4c0lLJ+ERc0ZS2YZhrrnC2qJzjHa0Qmtbi/T9DC062AW4nc9+WY+YZ6IH1vQBuU1PX5S+RSI= X-Received: by 2002:a05:6871:e7c7:b0:3d4:fed7:9a2a with SMTP id 586e51a60fabf-3e868ee3bbcmr3937531fac.10.1763242830883; Sat, 15 Nov 2025 13:40:30 -0800 (PST) Precedence: list list-help: list-unsubscribe: list-post: List-Id: x-ms-reactions: disallow MIME-Version: 1.0 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> In-Reply-To: <41c5eed0-dd1b-4ea4-99cf-f6d16682bd7f@app.fastmail.com> Date: Sat, 15 Nov 2025 22:40:19 +0100 X-Gm-Features: AWmQ_bkOYB5q4fe13ge0TOweuLwuAF08x7RBPgndtDfzPdvRRC7Ic3SbTX9fMZU Message-ID: Subject: Re: [PHP-DEV] Re: PHP True Async RFC Stage 5 To: Rob Landers Cc: Edmond Dantes , php internals , Larry Garfield Content-Type: multipart/alternative; boundary="000000000000966e780643a8f6d7" From: bukka@php.net (Jakub Zelenka) --000000000000966e780643a8f6d7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Nov 15, 2025 at 10:19=E2=80=AFPM Rob Landers wr= ote: > > > On Sat, Nov 15, 2025, at 22:17, Jakub Zelenka wrote: > > Hi, > > On Sat, Nov 15, 2025 at 8:56=E2=80=AFPM Rob Landers w= rote: > > > On Sat, Nov 15, 2025, at 15:41, Edmond Dantes wrote: > > Hello. > > > Based on the conversation so far, I=E2=80=99d imagine the list to look = something > like: > > Yes, that=E2=80=99s absolutely correct. When a programmer uses an operati= on > that would normally block the entire thread, 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 loc= al files > but can take seconds on NFS or with an HTTP URL. An array_map() *always* > blocks the thread but should *never* suspend. > > Without very clear rules, it becomes impossible 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 sp= elled out > directly; it makes it immediately clear which functions can or will suspe= nd > and prevents surprises. > > In the Async implementation, 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" creates an unstable > contract. > > Even something simple like: > > - if it can perform network IO > - if it can perform file/stream IO > - if it can sleep or wait on timers > > > 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 an= d > mainly clean implementation. We will need to carefully consider where the > suspension is going to be done. > > > My point is that it *should* be a part of the RFC. > But this is hard to know exactly. Also there will be always 3rd extensions that can block so we will need 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 stream internall poll that is used for stream IO in various places and could handles most suspensions including in mysqlnd. Then curl and sockets would 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 that can be merged for those parts. Kind regards, Jakub --000000000000966e780643a8f6d7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Nov 15,= 2025 at 10:19=E2=80=AFPM Rob Landers <rob@bottled.codes> wrote:
<= /div>

On Sat, Nov 15, 2025, at 22:17, Jakub Zelenka wr= ote:
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:
Hell= o.

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

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

I t= hink 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 fil= es but can take seconds on NFS or with an HTTP URL. An array_map() always blocks the thread but should neve= r suspend.

Without very clear rules, it become= s impossible 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 directly; it mak= es it immediately clear which functions can or will suspend and prevents su= rprises.

In the Async implementation, it will be s= pecified which functions are supported.

This is exactly the kind of thing that needs to be in the RFC itself. Re= lying on "the implementation will document it" creates an unstabl= e contract.

Even something simple like:
=
- if it can perform network IO
- if it can perform= file/stream IO
- if it can sleep or wait on timers

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.

My point is that it=C2=A0shoul= d be a part of the RFC.

But= this is hard to know exactly. Also there will be always 3rd extensions tha= t can block so we will need to do it piece by piece. You can just take it t= hat ideally everything that can block would be suspendable . The first cand= idate is surely stream internall poll that is used for stream IO in various= places and could handles most suspensions including in mysqlnd. Then curl = and sockets would be probably added. There are various other bits already p= resent in Edmonds PoC but we will need to consider them one by one.

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

Kind regards= ,

Jakub
--000000000000966e780643a8f6d7--