Hi, First of all, please don't top post.
On Thu, Nov 6, 2025 at 3:47 AM 韩天峰 <[email protected]> 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
