Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129113
Precedence: list
MIME-Version: 1.0
References: <CAEKnhAFZXqWH20Cy2g6-0c2V1Vd4w-N0M4xefzt6tTEp90+LqQ@mail.gmail.com>
 <0f38bc1a-ba13-43e1-9ee1-70085e75faa6@app.fastmail.com> <tencent_29925AB32FD591BD646C85A2@qq.com>
In-Reply-To: <tencent_29925AB32FD591BD646C85A2@qq.com>
Date: Thu, 6 Nov 2025 10:55:11 +0100
Message-ID: <CAEKnhAHmaD-C0s6+W51024vM_Wi4A4wQT-UPiuSHm0+mcCrjbQ@mail.gmail.com>
Subject: Re: Re: [PHP-DEV] [RFC] Polling API
To: =?UTF-8?B?6Z+p5aSp5bOw?= <rango@swoole.com>
Cc: Larry Garfield <larry@garfieldtech.com>, php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000004577e20642ea1077"
From: bukka@php.net (Jakub Zelenka)

--0000000000004577e20642ea1077
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

First of all, please don't top post.

On Thu, Nov 6, 2025 at 3:47=E2=80=AFAM =E9=9F=A9=E5=A4=A9=E5=B3=B0 <rango@s=
woole.com> wrote:

> I don't know what changes this proposal could bring to PHP if the aim is
> simply to introduce event loop mechanisms like epoll or kqueue.
>

The primary reason for this is to have an internal API that we can use
internally. The primary motivation was to actually have a better mechanism
for handling signals that can be safely used in ZTS. This is one of the
main blocker for introducing coroutine based TSRM mode that could be used
by FrankenPHP to use goroutines instead of threads. There was also related
timer issue on MacOS and at that time Arnaud came up with kqueue only PoC
implentation but we decided that it would be great to have something more
generic but we wanted something really minimal without a need for the whole
event loop abstraction like libuv or libevent (libev is dead AFAIC) offers.
After that I also had few other use cases in FPM as I wanted a bit more
generic event handling than what is currently there so I can use it in
child before accept. Note that we have got already its own event
implementation in FPM so this is more advancement in that area.

So when we have an internal API which we plan anyway, then I thought it
could be nice to also expose it to user space so project like AMPHP can use
it and effectively drop all other backends. In addition it didn't look good
that the only current polling mechanism for streams is based on select so
this is also effectively replacement for stream_select. Again not all users
using it need the full even loop.


> Why not make ext-uv (libuv) or ext-event (libev) built-in PHP extensions,
> just like ext-curl, ext-xml, or ext-bcmath?
>

Those are all optional extensions because they depend on external library.
Currently the only way how we could make it always available is to bundle
those libraries but especially libuv is quite bloated and adds unnecessary
overhead for our other use cases. We actually discussed it internally if we
should use or bundled libevent but the agreement between couple of core
devs was to create a simple polling API instead so here we are.

I will update the RFC and add more explanation there as this was also
requested by Larry and I can see that the motivation and primary use cases
for this are not exactly clear.

Thanks for the feedback.

Kind regards,

Jakub

--0000000000004577e20642ea1077
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi,</div><div><br></div><div>First of all, please don=
&#39;t top post.</div><br><div class=3D"gmail_quote gmail_quote_container">=
<div dir=3D"ltr" class=3D"gmail_attr">On Thu, Nov 6, 2025 at 3:47=E2=80=AFA=
M =E9=9F=A9=E5=A4=A9=E5=B3=B0 &lt;<a href=3D"mailto:rango@swoole.com">rango=
@swoole.com</a>&gt; wrote:<br></div><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 style=3D"font-family:Verdana;font-size:14px;color:rgb(0,0,0=
)"><div><div>I don&#39;t know what changes this proposal could bring to PHP=
 if the aim is simply to introduce event loop mechanisms like epoll or kque=
ue.=C2=A0</div></div></div></blockquote><div><br></div><div>The primary rea=
son for this is to have an internal API that we can use internally. The pri=
mary motivation was to actually have a better mechanism for handling signal=
s that can be safely used in ZTS. This is one of the main blocker for intro=
ducing coroutine based TSRM mode that could be used by FrankenPHP to use go=
routines instead of threads. There was also related timer issue on MacOS an=
d at that time Arnaud came up with kqueue only PoC implentation but we deci=
ded that it would be great to have something more generic but we wanted som=
ething really minimal without a need for the whole event loop abstraction l=
ike libuv or libevent (libev is dead AFAIC) offers. After that I also had f=
ew other use cases in FPM as I wanted a bit more generic event handling tha=
n what is currently there so I can use it in child before accept. Note that=
 we have got already its own event implementation in FPM so this is more ad=
vancement in that area.</div><div><br></div><div>So when we have an interna=
l API which we plan anyway, then I thought it could be nice to also expose =
it to user space so project like AMPHP can use it and effectively drop all =
other backends. In addition it didn&#39;t look good that the only current p=
olling mechanism for streams is based on select so this is also effectively=
 replacement for stream_select. Again not all users using it need the full =
even loop.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-le=
ft:1ex"><div style=3D"font-family:Verdana;font-size:14px;color:rgb(0,0,0)">=
<div><div>Why not make ext-uv (libuv) or ext-event (libev) built-in PHP ext=
ensions, just like ext-curl, ext-xml, or ext-bcmath?=C2=A0</div></div></div=
></blockquote><div><br></div><div>Those are all optional extensions because=
 they depend on external library. Currently the only way how we could make =
it always available is to bundle those libraries but especially libuv is qu=
ite bloated and adds unnecessary overhead for our other use cases. We actua=
lly discussed it internally if we should use or bundled libevent but the ag=
reement between couple of core devs was to create a simple polling API inst=
ead so here we are.</div><div><br></div><div>I will update the RFC and add =
more explanation there as this was also requested by Larry and I can see th=
at the motivation and primary use cases for this are not exactly clear.</di=
v><div><br></div><div>Thanks for the feedback.</div><div><br></div><div>Kin=
d regards,</div><div><br></div><div>Jakub</div><div><br></div><div>=C2=A0</=
div></div></div>

--0000000000004577e20642ea1077--