Async-std: Expose IoHandle or some way to register mio Evented

[passcod]

Currently this is hidden as an implementation detail of the network driver. Exposing would make it possible to hook up arbitrary Evented e.g. for other kernel event sources.

Perhaps this doesn't belong in async-std... in that case, maybe it could be extracted to another crate?

[sdroege]

IMHO this would indeed be very useful to have as public API for being able to write other crates that integrate with the async-std reactor/executor without having to reinvent all that again (plus spawning their own threads for it).

With mio being the de-facto standard for an abstraction over epoll and friends, it would also seem like the ideal choice for that.

However I remember there being talks about doing an API-breaking release soon, and it's not at 1.0 yet either so exposing mio types in the public API would potentially block an 1.0 release of async-std.

[passcod]

Hm, yeah. I wonder if it could be hidden behind a feature, marked unstable,
so to speak. That might be a bit much

On Sat, 17 Aug 2019, 08:01 Sebastian Dröge, [e-mail]
wrote:

IMHO this would indeed be very useful to have as public API for being able
to write other crates that integrate with the async-std reactor/executor
without having to reinvent all that again (plus spawning their own threads
for it).

With mio being the de-facto standard for an abstraction over epoll and
friends, it would also seem like the ideal choice for that.

However I remember there being talks about doing an API-breaking release
soon, and it's not at 1.0 yet either so exposing mio types in the public
API would potentially block an 1.0 release of async-std.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/async-rs/async-std/issues/60?email_source=notifications&email_token=AABGBC44MTJR2DFSRJZ7S6LQE6O4JA5CNFSM4IMNKY62YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4QFCMQ#issuecomment-522211634,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABGBC6ADYRR6CFDUWZNNXTQE6O4JANCNFSM4IMNKY6Q
.

[sdroege]

I believe that might be a valid way forward for the time being until mio or an alternative is 1.0-stable.

[ghost]

I would suggest creating rolling your own mio::Poll instance and maybe driving it in a separate thread rather than attempting to hook into async-std.

We're hesitant about exposing mio's interface mainly because we might replace it with a different library in the not-too-distant future.

[passcod]

Yeah, that's what I wanted to avoid, because it's a lot of boilerplate and
not easy to get right and also kinda feels like defeating the point to have
N completely different drivers for each thing that plugs in. Not in scope
at the moment, that's okay

On Sun, 18 Aug 2019, 16:00 Stjepan Glavina, [e-mail]
wrote:

I would suggest creating rolling your own mio::Poll instance and maybe
driving it in a separate thread rather than attempting to hook into
async-std.

We're hesitant about exposing mio's interface mainly because we might
replace it with a different library in the not-too-distant future.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/async-rs/async-std/issues/60?email_source=notifications&email_token=AABGBC6JABPYRE6UB7YVBATQFFPXXA5CNFSM4IMNKY62YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4RBYQI#issuecomment-522329153,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABGBC5KPHVDE5YDKXGNLSLQFFPXXANCNFSM4IMNKY6Q
.

[yoshuawuyts]

Full agree with @stjepang here. Wanted to add that I'm also sympathetic to having the ability to hook into async-std's io event loop, and it'd be interesting in findings ways to do so. But given the main benefit is mostly for performance, I agree it's not quite a priority at the moment.

[sdroege]

But given the main benefit is mostly for performance

I'd say the main benefit is that it reduces the amount of boilerplate and code duplication considerably, and thus the maintenance burden on other crates. But of course it increases it here by having some more API surface to care about.

For the time being, would you accept a PR that adds something behind some kind of unstable feature flag here as long as it's not very intrusive?

[yoshuawuyts]

This is not something that's a priority in the short/medium term. Spawning a separate event event loop seems like a reasonable intermediate solution.

Going to go ahead and close this to remove it from our active backlog, but this is definitely something we may want to revisit in the future!

[mzji]

How about label this issue as postponed? It will be useful for reminding us to revisit these issues when we want.

[yoshuawuyts]

We don't have such a label yet, and out of experience it's not usually something that gets looked at. This is bound to keep coming up though, so I think we'll be fine.

Marked it as "api design" for now, as that feels the closest reason why we couldn't move forward with this (: