-
-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Need an interface to poll arbitrary kqueue filters in Tokio 0.3 #3197
Comments
I don't think that would be sufficient, because for |
I don't understand the problem with mio. Is it that mio is Unix specific? Or that you think Tokio's public API would be too fragile if it depended on mio's public API? |
The problem is that we are releasing Tokio 1.0 very soon at which point we guarantee no more breaking releases of Tokio for at least 3 years, and support of 1.0 for at least 5 years. If mio is visible in the public API, then we will not be able to upgrade Tokio in case of a breaking change in mio. This was a big problem in Tokio 0.2, which was stuck on mio 0.6 even though mio 0.7 had been released a long time ago. |
What if Tokio reexports that interface? It doesn't even have to be a pass-through reexport. Tokio could create its own trait that basically does the same thing as mio's |
It's a bit more complicated than that. IMO PollEvented is too broad of an abstraction to have at the core. This is fairly obvious w/ windows, but also on linux, there is no guarantee that there is a epoll poller. There could be uring. It's definitely an interesting problem. I will have to think about it a bit more. Exposing Personally, I don't hate the sub reactor strategy. |
What about exposing |
@carllerche now that 1.0 is out, are you willing to reconsider this request? I only see two decent options:
|
It should be possible to expose kqueue specifics on
The next steps would be to propose specific API additions in here or a new issue. We can discuss those, and then move forward w/ a PR once we reach something that works. |
I don't see how For POSIX AIO, I could create a type that implements I still can't find any option better than exposing |
Unlike every other kqueue event source, POSIX AIO registers events not via kevent(2) but by a different mechanism that needs the kqueue's file descriptor. This commit adds a new `PollAio` type, designed to be used by an external crate that implements a POSIX AIO Future for use with Tokio's reactor. fixes tokio-rs#3197
Unlike every other kqueue event source, POSIX AIO registers events not via kevent(2) but by a different mechanism that needs the kqueue's file descriptor. This commit adds a new `PollAio` type, designed to be used by an external crate that implements a POSIX AIO Future for use with Tokio's reactor. Fixes: tokio-rs#3197
Unlike every other kqueue event source, POSIX AIO registers events not via kevent(2) but by a different mechanism that needs the kqueue's file descriptor. This commit adds a new `PollAio` type, designed to be used by an external crate that implements a POSIX AIO Future for use with Tokio's reactor. Fixes: tokio-rs#3197
@carllerche what do you think about PR #3841 ? Instead of exposing PollEvented, I created a new, similar structure. It only has the minimum API needed for POSIX AIO. AFAIK, that makes it useless for any other application, so I named it PollAio. It's the smallest API addition I could come up with. |
Unlike every other kqueue event source, POSIX AIO registers events not via kevent(2) but by a different mechanism that needs the kqueue's file descriptor. This commit adds a new `PollAio` type, designed to be used by an external crate that implements a POSIX AIO Future for use with Tokio's reactor. Fixes: tokio-rs#3197
Unlike every other kqueue event source, POSIX AIO registers events not via kevent(2) but by a different mechanism that needs the kqueue's file descriptor. This commit adds a new `PollAio` type, designed to be used by an external crate that implements a POSIX AIO Future for use with Tokio's reactor. Fixes: tokio-rs#3197
Is your feature request related to a problem? Please describe.
With Tokio 0.1 and 0.2 I could create a custom implementation of
mio::Evented
that worked with any sort of kqueue filter, and build futures on that usingtokio::io::PollEvented
. However,PollEvented
is no longer publicly exposed in Tokio 0.3. The suggested replacement,AsyncFd
, only works for raw file descriptors. Basically, it's used for socket-like things. AFAICT, tokio 0.3 provides no facility to poll arbitrary kqueue filters.Describe the solution you'd like
Ideally
PollEvented
would be public again.Describe alternatives you've considered
I could create a new kqueue file descriptor for my future, registry my future to that, and poll that kqueue with
AsyncFd
. But that would require me to handlekevent(2)
myself, and I would have to create a new kqueue for every single future I make. Either that, or basically create some kind of subreactor just for all futures using my kqueue filter. Basically, I would have to reimplement a large chunk of Tokio.Additional context
PollEvented
include:EVFILT_VNODE
: notifies about file system events like file creation and deletionEVFILT_SIGNAL
: notifies about reception of a signal. I'm not sure how tokio is currently handling signals, but it isn't doing it this way.EVFILT_TIMER
: the subject of issue AsyncFd doesn't allow to decide read/write interest making kqueue's fd fail in tokio 0.3 #3072 .EVFILT_USER
: user-triggered kqueue events.EVFILT_SENDFILE
: notification for completion of an asynchronous sendfile(2) operation.The text was updated successfully, but these errors were encountered: