Re: [RFC] Polling API

From: Date: Sun, 18 Jan 2026 12:23:56 +0000
Subject: Re: [RFC] Polling API
References: 1  Groups: php.internals 
Request: Send a blank email to internals+get-129778@lists.php.net to get a copy of this message
Hi On 10/30/25 22:06, Jakub Zelenka wrote:
I would like to introduce a new polling API RFC that is part of my stream evolution work: https://wiki.php.net/rfc/poll_api
Since you made some larger changes to the RFC, rather than checking each change individually, I've taken another full look at the RFC and have the following remarks: - Context::wait() takes a millisecond timeout. This feels insufficiently granular. I am wondering if we should rather use either micro (as returned by microtime) or nanoseconds (as returned by hrtime) - or possible an instance of DateInterval (which would use microsecond resolution). - For Handle: I assume that getFileDescriptor() should be abstract? - For Handle I am wondering about abstract class vs interface. Since the Handle presumably doesn't have any non-abstract methods, an interface feels more correct / more flexible. - For Handle: What happens if I extend this class in userland and attach it to a Context. Will things break? What if I return the number of a non-existent FD? - For the stubs: It would be useful if you used the “generics notation” for the array returns. e.g. @return list<Backend> for Backend::getAvailableBackends(). This makes it easier to understand how exactly the result will look like to check for mistakes / suboptimal choices. - InactiveWatcherException: This one feels more like a programmer error, so should possibly be a PollError / InactiveWatcherError (but I don't know enough about the topic to be sure). - Internal API: For php_poll_wait(), the timeout should probably be a struct timespec for future-proofing. - Policy-wise: I just added the Abstain option to the voting widget. - Examples: I like them. They nicely showcase how the API works! Best regards Tim Düsterhus

« previous php.internals (#129778) next »