Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128989
Precedence: list
MIME-Version: 1.0
References: <CAMW7n8DGbFnQzjt3s9CcOBwhp+MUOV+K3U=yY=ULOTdUXaOLHQ@mail.gmail.com>
 <CAMW7n8BxmAC56LZ4qA6oJp0kFhhPMuLdqfmzeSVQrf6woR9GyA@mail.gmail.com>
 <889d3042-7b3e-4152-bd8c-09bbcc967309@app.fastmail.com> <CAMW7n8D-+t90mQyPLm1N8M0GyKiAS0Z4U0C--=Qj33zSSzuMHQ@mail.gmail.com>
 <b4890197-9ecf-412b-a2ba-3f63e12def19@app.fastmail.com>
In-Reply-To: <b4890197-9ecf-412b-a2ba-3f63e12def19@app.fastmail.com>
Date: Tue, 28 Oct 2025 11:35:05 +0100
Message-ID: <CAEKnhAHvFYp5PDoMcYAYYNVcpLMLMoTuVj2idug9GtKTgNA-Qw@mail.gmail.com>
Subject: Re: [PHP-DEV] Re: PHP True Async RFC Stage 4
To: Rob Landers <rob@bottled.codes>
Cc: Edmond Dantes <edmond.ht@gmail.com>, Larry Garfield <larry@garfieldtech.com>, 
	php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000005fb5b50642359292"
From: bukka@php.net (Jakub Zelenka)

--0000000000005fb5b50642359292
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Oct 27, 2025 at 7:14=E2=80=AFPM Rob Landers <rob@bottled.codes> wro=
te:

>
> As far as I understand, the only thing missing from php-src that would
> allow everything to be async is a Fiber scheduler. We already have tons o=
f
> Fiber libraries out there ...
>

I'm not sure if Fibers were particular success. They are quite hard to use
and you need an extra library like amp so I think it would be useful to
give users a solution that is available in the core. I think this would
give it a bit more trust as it will also get the security guarantees
(standard core support for handling security issues). It will take time and
there will be multiple RFC's to get there and the implementation will also
require thorough review. So splitting that to smaller pieces is quite
important.

That said I'm planning introduction of better API for polling (almost done
and soon to be announced) that will be using special polling handles that
will be available for streams, sockets, curl and possible other extensions.
Streams should then get special notification callbacks that would be called
before IO and most likely provide the polling handle as a parameter so this
could be used by user space in their own reactor / scheduler. I plan to
also provide a similar internal API so async can integrate cleanly into
this without overwriting stream polling function as it's the case in the
current implementation. Similar API should be also provided for curl (Joe
already created part of it), sockets and possible other exts. In other
words, the user space should be able to gain this functionality and the
async core extension would be more core internal user of it.

The above is just for sockets and there will be needed further work for
file IO. I'm preparing new PHP IO internal API that will be initially
mainly for copying but will allow extension for other operations including
file operations and will use io_uring on Linux. I'm still not sure how to
best expose it to user space as the ring entry completion don't have usual
polling flow so it does not exactly fit into those callbacks. We could
possible do some sort pipe and thread that would process the completion
queue but maybe there is a better solution. This is still TBD but usually
file IO is not the main IO blocker so this can come a bit later.

We will also need to think about DNS resolving that might be even trickier
and might require IO thread pools - those might be needed as a backup
solution for platform that don't support io_uring anyway.

I think those API's will be also prerequisites for this async to implement
this functionality as I'm not fond of adding some hacks and functionality
duplication (that would be quite a pain for maintenance).

Kind regards,

Jakub

--0000000000005fb5b50642359292
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Mon, Oct 27, 2025 at 7:14=E2=80=AFPM R=
ob Landers &lt;rob@bottled.codes&gt; wrote:</div><div class=3D"gmail_quote =
gmail_quote_container"><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><d=
iv><br></div><div>As far as I understand, the only thing missing from php-s=
rc that would allow everything to be async is a Fiber scheduler. We already=
 have tons of Fiber libraries out there ...=C2=A0<br></div></blockquote><di=
v><br></div><div>I&#39;m not sure if Fibers were particular success. They a=
re quite hard to use and you need an extra library like amp so I think it w=
ould be useful to give users a solution that is available in the core. I th=
ink this would give it a bit more trust as it will also get the security gu=
arantees (standard core support for handling security issues). It will take=
 time and there will be multiple RFC&#39;s to get there and the implementat=
ion will also require thorough review. So splitting that to smaller pieces =
is quite important.</div><div><br></div><div>That said I&#39;m planning int=
roduction of better API for polling (almost done and soon to be announced) =
that will be using special polling handles that will be available for strea=
ms, sockets, curl and possible other extensions. Streams should then get sp=
ecial notification callbacks that would be called before IO and most likely=
 provide the polling handle as a parameter so this could be used by user sp=
ace in their own reactor / scheduler. I plan to also provide a similar inte=
rnal API so async can integrate cleanly into this without overwriting strea=
m polling function as it&#39;s the case in the current implementation. Simi=
lar API should be also provided for curl (Joe already created part of it), =
sockets and possible other exts. In other words, the user space should be a=
ble to gain this functionality and the async core extension would be more c=
ore internal user of it.</div><div><br></div><div>The above is just for soc=
kets and there will be needed further work for file IO. I&#39;m preparing n=
ew PHP IO internal API that will be initially mainly for copying but will a=
llow extension for other operations including file operations and will use =
io_uring on Linux. I&#39;m still not sure how to best expose it to user spa=
ce as the ring entry completion don&#39;t have usual polling flow so it doe=
s not exactly fit into those callbacks. We could possible do some sort pipe=
 and thread that would process the completion queue but maybe there is a be=
tter solution. This is still TBD but usually file IO is not the main IO blo=
cker so this can come a bit later.</div><div><br></div><div>We will also ne=
ed to think about DNS resolving that might be even trickier and might requi=
re IO thread pools - those might be needed as a backup solution for platfor=
m that don&#39;t support io_uring anyway.</div><div><br></div><div>I think =
those API&#39;s will be also prerequisites for this async to implement this=
 functionality as I&#39;m not fond of adding some hacks and functionality d=
uplication (that would be quite a pain for maintenance).</div><div><br></di=
v><div>Kind regards,</div><div><br></div><div>Jakub</div></div></div>

--0000000000005fb5b50642359292--