Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126548
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_6822597E-085E-436E-A98C-1AA4A9FDB30E"
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.400.131.1.6\))
Subject: Re: [PHP-DEV] PHP True Async RFC
Date: Mon, 3 Mar 2025 11:20:10 +0100
References: <CAMW7n8AJckEDzhGv9BdjNhq8zAdCqb4HsVr56vGi+izw50X6Dg@mail.gmail.com>
 <cdaaf51e-6266-4434-8606-7520ac0940d9@app.fastmail.com>
 <CAMW7n8A-rDXQe9Dh1hT28vMuyJvmeKO=JogJ0zsy9Y5Sjc-0_g@mail.gmail.com>
To: internals@lists.php.net
In-Reply-To: <CAMW7n8A-rDXQe9Dh1hT28vMuyJvmeKO=JogJ0zsy9Y5Sjc-0_g@mail.gmail.com>
Message-ID: <B2B1627A-2BBA-48A5-B72A-A46D33DF785D@daniil.it>
From: daniil@daniil.it (Daniil Gentili)


--Apple-Mail=_6822597E-085E-436E-A98C-1AA4A9FDB30E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi,
> Any Fiber can be canceled at any time, and there is no need to use =
explicit Cancellation, which I personally find an inconvenient pattern.=20=

>=20
As a heavy use of both amphp and go, cancellations (contexts in go) are =
absolutely needed, as a fiber may spawn further background fibers in =
order to execute some operation, just cancelling that specific fiber =
will not cancel the spawned fibers, unless a bunch of boilerplate =
try-catch blocks are added to propagate CancellationExceptions.=20

A nicer API should use only explicit cancellation objects, as this =
pattern of preemptive implicit cancellations (i.e. a fiber may be =
cancelled at any point via cancel()) is super dangerous IMO, as it can =
lead to all sorts of nasty behaviour: what if we cancel execution of a =
fiber in the middle of a critical section (i.e. between a lock() and an =
unlock() of a file or a database? What if unlocking() in the catch =
(CancelledException) block requires spawning a new fiber as part of the =
interaction with the database?).
Consider also the huge amount of CancelledException blocks that would =
have to be added to handle state cleanup in case of premature implicit =
cancellations, as opposed to explicit cancellations that only throw when =
we ask them to: there=E2=80=99s a reason why golang, amphp & others use =
explicit cancellations.

Another thing I=E2=80=99m not happy with is how unless the scheduler is =
launched, all code executes in blocking mode: this seems like a super =
bad idea, as it will hold back the ecosystem again, and create a split =
in the project similar to JIT (i.e. a separate =E2=80=9Cexecution =
mode=E2=80=9D with its own bugs, that get fixed slowly because few =
people are using it, and few people are using it because of its bugs).
The main reason given in the RFC (Code written without using the =
Scheduler should not experience any side effects) makes no sense, =
because legacy code not spawning fibers will not experience concurrency =
side effects anyway, regardless of whether the scheduler is started or =
not.

A thing I would love to see, on the other hand, is for Context to become =
a =E2=80=9Cprovider=E2=80=9D for superglobals such as $_REQUEST, $_POST, =
$_GET, and all globals in general (and perhaps all other global state =
such as static properties): this would allow to very easily to turn i.e. =
php-fpm into a fully asynchronous application server, where each request =
is started in the same thread (or in N threads in an M-N M>N execution =
model) but its global state is entirely isolated between fibers.

Regards,
Daniil Gentili - Senior software engineer=20

Portfolio: https://daniil.it <https://daniil.it/>
Telegram: https://t.me/danogentili=

--Apple-Mail=_6822597E-085E-436E-A98C-1AA4A9FDB30E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; =
charset=3Dutf-8"></head><body style=3D"overflow-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: =
after-white-space;">Hi,<br><div><blockquote type=3D"cite"><div =
dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><p>Any =
<strong>Fiber</strong> can be canceled <strong>at any time</strong>, and =
there is <strong>no need</strong> to use <strong>explicit =
Cancellation</strong>, which I personally find an inconvenient =
pattern.&nbsp;</p></div></div></div></blockquote></div>As a heavy use of =
both amphp and go, cancellations (contexts in go) are absolutely needed, =
as a fiber may spawn further background fibers in order to execute some =
operation, just cancelling that specific fiber will not cancel the =
spawned fibers, unless a bunch of boilerplate try-catch blocks are added =
to propagate CancellationExceptions.&nbsp;<div><br></div><div>A nicer =
API should use only explicit cancellation objects, as this pattern of =
preemptive implicit cancellations (i.e. a fiber may be cancelled at any =
point via cancel()) is super dangerous IMO, as it can lead to all sorts =
of nasty behaviour: what if we cancel execution of a fiber in the middle =
of a critical section (i.e. between a lock() and an unlock() of a file =
or a database? What if unlocking() in the catch (CancelledException) =
block requires spawning a new fiber as part of the interaction with the =
database?).</div><div>Consider also the huge amount of =
CancelledException blocks that would have to be added to handle state =
cleanup in case of premature implicit cancellations, as opposed to =
explicit cancellations that only throw when we ask them to: there=E2=80=99=
s a reason why golang, amphp &amp; others use explicit =
cancellations.</div><div><br></div><div>Another thing I=E2=80=99m not =
happy with is how unless the scheduler is launched, all code executes in =
blocking mode: this seems like a super bad idea, as it will hold back =
the ecosystem again, and create a split in the project similar to JIT =
(i.e. a separate =E2=80=9Cexecution mode=E2=80=9D with its own bugs, =
that get fixed slowly because few people are using it, and few people =
are using it because of its bugs).</div><div>The main reason given in =
the RFC (Code written without using =
the&nbsp;<code>Scheduler</code>&nbsp;should not experience any side =
effects) makes no sense, because legacy code not spawning fibers will =
not experience concurrency side effects anyway, regardless of whether =
the scheduler is started or not.</div><div><br></div><div>A thing I =
would love to see, on the other hand, is for Context to become a =
=E2=80=9Cprovider=E2=80=9D for superglobals such as $_REQUEST, $_POST, =
$_GET, and all globals in general (and perhaps all other global state =
such as static properties): this would allow to very easily to turn i.e. =
php-fpm into a fully asynchronous application server, where each request =
is started in the same thread (or in N threads in an M-N M&gt;N =
execution model) but its global state is entirely isolated between =
fibers.</div><div><br></div><div>Regards,</div><div>Daniil Gentili - =
Senior software engineer&nbsp;</div><div><br>Portfolio:&nbsp;<a =
href=3D"https://daniil.it">https://daniil.it</a></div><div>Telegram:&nbsp;=
<a =
href=3D"https://t.me/danogentili">https://t.me/danogentili</a></div></body=
></html>=

--Apple-Mail=_6822597E-085E-436E-A98C-1AA4A9FDB30E--