Description
tl;dr -- wherein we converge on libuv
Some thoughts that I put in a ticket comment before realizing that they didn't really apply.. still wanted to save it, though.
the plan is somewhat roughly-sketched-out; i think it's something like:
- do Towards a pluggable EventLoop, etc #9128
- decide whether or how and at what API boundary to draw the line (possibly at the
RtioFoointerfaces) - assuming the above bullet holds, re-implement all of the
RtioFootraits in a new module (a sibling tostd::rt::uv), that uses "platform-backed" implementations using idiomatic APIs for each platform (so mostly POSIX/etc on linux, POSIX+NSFooon OSX, win32 on windows, etc...) .
There would be stuff like RtioTimer (where we have std::io::timer::Timer probably implementing std::select::Select in the near future, unless we want to go down the rabbit hole and move std::select's entire impl to be behind the IoFactory.. then maybe we could do something rational at the per-platform/OS level) that might not translate cleanly. I'd love to identify a subset of the RtioFoo traits (or maybe at some other boundary? not sure) that we can definitely do all of in a notional std::rt::pb module (pb for platform-backed).
An additional caveat to the third bullet, above, is that these implementations would be "truly blocking" and would do no task-descheduling-magicks (as is done, currently, in uvio), so they could be conceivably used without the rust scheduler. Not sure how to get around in case(s) where the platform API is async (this is bound to come up, I'm sure). Hence my hedging as outlined in bullet 1. This fact (no scheduler/runtime interaction in pb) suggests that maybe it should live outside of std::rt.. std::unstable? Still the question of a common API between std::rt::io and pb, though.
@brson and I have had a few conversations about this in IRC, and I have a topic branch working towards #9128 in my local repo. But not much actual movement on this.