Library that wraps blocking IO system calls with a 1:1-threaded task.

[bblum]

jld mentioned on IRC that it would be bad if a blocking IO system call blocked the entire rust scheduler thread, so that it couldn't schedule other threads in the meantime.

It would be useful to have a library which wraps blocking IO calls with a call to task::task().sched_mode(manual_threads(1)).spawn so that when the kernel blocks that thread rust can schedule other threads on the existing scheduler. (The calling task would block on the exit+response of the 1:1-threaded task.)

An interesting researchy/heuristic problem part of this would be figuring out when it would be more expensive to create the new scheduler thread than to just call and block directly.

[atris]

That means,creating a new kernel thread and mapping it to the blocking IO thread?

[bblum]

Yes.

[atris]

I think it would be better to create a new kernel thread and map it to the blocking IO thread.This way,rust scheduler probably doesnt have to worry about the blocking thread and the OS can still schedule and manage the blocking thread.

[bblum]

Is that not what you/I just said in the previous comments? I believe this is the same thing.

The rust scheduler should have to worry about the blocking thread. On a machine with 1 CPU (and hence 1 scheduler thread by default), the task that invokes this library wrapper should block in a rust-scheduler-enabled way so that other tasks may run while the IO completes.

[atris]

Yeah,

It is just an old habit to confirm my thinking :)

Yeah,I agree...I missed the point a bit...

[msullivan]

Is this how we want to do this? I was under the impression that we were going to use wrappers based on non-blocking IO.

[msullivan]

Closing this, since it isn't the approach we want for most of our IO functions, and it isn't clear whether there is library code currently for which it is the right approach.