Replies: 1 comment 1 reply
-
The short answer is: no. io_uring has involved quite a bit since the initial set of opcodes supported, one of which was the poll part. These days nobody should use it for cases where they could just be doing a recv/read/etc. There's also no reason to use the epoll opcode to manage an epoll instance. I did try and deprecate that one, but of course some library already used it... |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I would like to understand if/why the two poll interfaces are still relevant with io_uring and what their differences are.
It is my understanding that many traditional use cases would no longer apply, for example instead of waiting for
POLLOUT
and then issuing a write operation, the latter can be issued straight away to eventually complete. On the other hand, I can see cases though where the poll interfaces might still be useful, for example, to provide data for writes only when it can be written/sent at all. Also, there are specialties likePOLLPRI
.So, for a start, is my understanding correct that the traditional event loop use case for poll-ish interfaces largely goes away with io_uring or are there natural uses cases still?
Secondly, if, for whatever reason a poll-ish interface is needed and the specialties of epoll are not required, is there a relevant difference, say, between issuing a IORING_OP_POLL_ADD and adding a oneshot fd with IORING_OP_EPOLL_CTL? In particular, is there a relevant difference in performance, that is, a relevant advantage of epoll?
Beta Was this translation helpful? Give feedback.
All reactions