IO.select support

[jscheid]

Do I understand correctly that Fiber::Scheduler.io_select is not currently supported by Async, but io_wait is?
And that therefore, if I wanted to wait on multiple fds simultaneously, I need to run one Task per fd?

[ioquatix]

That's correct, it looks like I never got around to implementing it.

It's extremely hard to emulate, so it's likely we would just punt it off to a thread, e.g. Thread.new{::IO.select(...)}.value - unless you have a better idea?

I'm okay to add support for this fiber scheduler hook if you think the benefit is worth it.

[jscheid]

I saw code to that effect (Thread.new) in io-event - it's dead code at the moment I assume?

It would be great to find a solution without a thread, but sounds like you're pessimistic.

When you say "extremely hard to emulate", you're talking about race conditions with regard to readiness?

[jscheid]

I can see cases where a caller of IO.select makes an assumption that multiple fds are already ready simultaneously - but that's a case we could handle by calling IO.select with zero timeout.

I can't really see a case where a caller can assume that two fds become available at exactly the same point in time, there's just too much jitter. I wonder if we could exploit that fact to simplify the problem, by short circuiting as soon as any launched Task returns non-alive after start (without yielding)? If all launched Tasks return alive, the first that returns from io_wait can interrupt the others. If a Task is DOA, interrupt the ones that were started before.

This is not a fully formed thought, just an idea so far. I might very well be missing something obvious.

[ioquatix]

It’s tricky to emulate efficiently, re-arming all the file descriptors will be expensive. There are no direct analogues in epoll or kqueue where basically we’d need to emulate every detail of the system call. Cancellation is also expensive.

[jscheid]

Yeah, that makes sense. But I wonder where is the cutoff point in terms of number of fd. For a single fd I'm pretty sure a single IO.wait will be cheaper than spawning the thread (and cheaper than waking up a reusable side thread through a Mutex) - or at least roughly on par? For a hundred fds I'm certain a Thread will be cheaper.

In my use case I'll have a dozen fds at most, probably 1-5 on average. I've put together a little experiment here (for my use case I could skip io_select and go straight to io_select_inner). I might try and run a few benchmarks on real workloads later this week, in the meantime, I'd be curious if you have an estimate where the cutoff point might be.

[ioquatix]

Your implementation is basically what I imagine it would look like - multiplexing tasks for each IO.