Re: [RFC] Polling API
| From: | Tim Düsterhus | 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_apiSince 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