On Mon, Oct 27, 2025 at 7:14 PM Rob Landers <[email protected]> wrote:
> > 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 of > 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
