Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126556
Precedence: bulk
MIME-Version: 1.0
References: <CAMW7n8AJckEDzhGv9BdjNhq8zAdCqb4HsVr56vGi+izw50X6Dg@mail.gmail.com>
 <cdaaf51e-6266-4434-8606-7520ac0940d9@app.fastmail.com> <CAMW7n8A-rDXQe9Dh1hT28vMuyJvmeKO=JogJ0zsy9Y5Sjc-0_g@mail.gmail.com>
 <B2B1627A-2BBA-48A5-B72A-A46D33DF785D@daniil.it> <CAMW7n8CnaOEvV4BiMwBh+02==EaoD5nMTjzuq7ATb4RAvRhUmQ@mail.gmail.com>
 <E0EFE00D-07E7-47A1-89C2-865E90812E7B@daniil.it>
In-Reply-To: <E0EFE00D-07E7-47A1-89C2-865E90812E7B@daniil.it>
Date: Mon, 3 Mar 2025 20:26:43 +0200
Message-ID: <CAMW7n8AxhKWDqFfBucdYnwqcWBdAGErBN1m-2gDZsV2BJPTuOg@mail.gmail.com>
Subject: Re: [PHP-DEV] PHP True Async RFC
To: Daniil Gentili <daniil@daniil.it>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000e63551062f744c0c"
From: edmond.ht@gmail.com (Edmond Dantes)

--000000000000e63551062f744c0c
Content-Type: text/plain; charset="UTF-8"

>
> Note the explicit use case I listed is that of an unlock() in a finally
> block that *requires spawning a new fiber* in order to execute the actual
> unlock() RPC call: this is explicitly in contrast with the RFC, which
> specifies that
> >*ATTENTION*: A programmer must *never* attempt to create a new fiber
> while handling a CancellationException, as this behavior may trigger an
> exception during *Graceful Shutdown* mode.
>
>
I think you are right. This restriction increases complexity without
providing significant benefits. I will remove this condition from the RFC
entirely and simply state that the programmer should handle such situations
carefully.
Thank you!

--000000000000e63551062f744c0c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><div class=3D"gmail_quote gmail=
_quote_container"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><d=
iv><br></div>Note the explicit use case I listed is that of an unlock() in =
a finally block that *requires spawning a new fiber* in order to execute th=
e actual unlock() RPC call: this is explicitly in contrast with the RFC, wh=
ich specifies that=C2=A0</div><div>&gt;<strong>ATTENTION</strong>: A progra=
mmer must=C2=A0<strong>never</strong>=C2=A0attempt to create a new fiber wh=
ile handling a=C2=A0<code>CancellationException</code>, as this behavior ma=
y trigger an exception during=C2=A0<strong>Graceful Shutdown</strong>=C2=A0=
mode.</div><div><br></div></blockquote><div><br></div><div>

I think you are right. This restriction increases complexity without provid=
ing significant benefits. I will remove this condition from the RFC entirel=
y and simply state that the programmer should handle such situations carefu=
lly.=C2=A0</div><div>

Thank you!

=C2=A0=C2=A0</div></div></div>

--000000000000e63551062f744c0c--