Support for mio 0.7? - Githubissues

jgallagher commented 4 years ago

Hi! I was taking a stab at upgrading a crate of mine that uses mio 0.6 and mio-extras 2.0 to mio 0.7, which made significant API changes (cf blog post linked to by the mio CHANGELOG). An immediate change is that Evented has been replaced by Source; I haven't looked too deeply at whether the other changes impact mio-extras more severely.

I realize this crate is in maintenance mode and this may be beyond the scope of what you were hoping to do. Any interest in pursuing this? Or would you be open to a PR moving to mio 0.7? I assume that would require a major version bump on mio-extras to 3.0.

jgallagher commented 4 years ago

The removal of Registration and SetReadiness looks like a much more painful change.

dimbleby commented 4 years ago

I'm unlikely to do this myself; but if you - or anyone else - would like to contribute a PR then I'd absolutely be open to merging and publishing.

kaimast commented 4 years ago

@jgallagher let me know if you need help with this. I don't use this crate but would like to see winit to be upgraded to mio 0.7...

jgallagher commented 4 years ago

@kaimast I'm not currently working on this. I'm not exactly sure what to do given the discussion on tokio-rs/mio#1289. For my crate I might be able to use the suggestion there and drop mio-extras altogether (and embed the timeouts into my polling loop), although I'd rather not do that. But given the restriction of a single Waker per Poll, I don't know how you'd implement mio-extra's timers which have no such restriction.

kaimast commented 4 years ago

You're right. I don't think this is feasible without extensively changing mio-extra's API. Might be easier to just remove winit's dependency on mio-extra at this point.

onurzdg commented 4 years ago

I recently built mio-misc as an alternative. Feedback is appreciated.

dimbleby commented 4 years ago

I'm basically not expecting to do anything much with mio-extras myself and haven't yet looked at your code, but:

if you want to submit a pull request, to get your code into this project, I expect I'd be likely to accept it
- that's doubly true if you'd be willing for me to give you commit permissions on this repository, and indicate that you're expecting to stick around and fix issues if needed
or if you prefer to publish mio-misc as an independent project, I'd gladly accept a pull request that directed people towards it

przygienda commented 3 years ago

yeah, 0.7 definitely lowered mio qualilty. I'm trying to move to 0.7 but gave up due to lack of timers as well. Looked quickly @ what it would take to pull this crate up to 0.7 but yeah, MIO architecture changed drastically on 0.7 and not for the better.

danieleades commented 3 years ago

mio-extras and mio-misc don't quite have feature parity.

see comment here - https://github.com/onurzdg/mio-misc/issues/8#issue-1021654328

Thomasdezeeuw commented 1 year ago

I've been looking through the crates that are still using Mio v0.6, which by the way is no longer supported, and found this crate/issue. I realise that we've made a number of breaking changes in Mio v0.7 to make the API smaller and that meant that Mio-extras doesn't work with Mio v0.7/v0.8.

The unfortunate truth is that Mio isn't really the right abstraction for a timer or channel implementation. Mio (now) focusses on I/O, dropping everything unrelated to that. Depending on the use case you're already looking pretty similar to a complete (Futures) runtime.

As more concrete solution to move forward:

For channel you can use a pipe to emulate Mio events, it's something I do for example here: https://github.com/Thomasdezeeuw/heph/blob/34a8adc74c32572c8b56d6fef3053161f32953c3/rt/src/channel.rs.
The timers a more tricky to recreate. For Linux their is always timerfd(2) and kqueue has it's own timer support, but neither can beat an in user space implementation when it comes to performance.

More concrete recommendations I can't give without know more of the usage, but I'm always willing to help, just have to ask (ping me on GitHub or Mio's Discord channel).

yeah, 0.7 definitely lowered mio qualilty. I'm trying to move to 0.7 but gave up due to lack of timers as well. Looked quickly @ what it would take to pull this crate up to 0.7 but yeah, MIO architecture changed drastically on 0.7 and not for the better.

@przygienda can you elaborate on this?

dimbleby commented 1 year ago

While I'd be happy to merge pull requests here that made life easier for folk, I'd also be more than happy to see crates move on to recent versions of mio and drop their mio-extras dependency altogether.

To that end I'd suggest that a good line of attack would be to work through https://crates.io/crates/mio-extras/reverse_dependencies, and figure out what is stopping those crates from getting current.

WindSoilder commented 1 year ago

Currently the newest mio version is 0.8

dimbleby / mio-extras

Support for mio 0.7? #7