Comment by throwawaymaths
Comment by throwawaymaths a day ago
> Wouldn't this only work if there's only one implementation throughout the entire compliation unit
in practice how often are people using more than one io in a program?
Comment by throwawaymaths a day ago
> Wouldn't this only work if there's only one implementation throughout the entire compliation unit
in practice how often are people using more than one io in a program?
one of the io interfaces provided is a standard threadpool io. and if it was really important, you could write your own io interface that selects between std threadpool and std blocking based off of an option (i am guessing, i don't know, but seems reasonable)
In larger Rust applications or servers I find myself doing this very often -- for example, one application I'm working on mostly uses blocking I/O for occasional filesystem access but has a little bit of async networking.
I think having a thread pool on top of some evented IO isn't _that_ uncommon.
You might have a thread pool doing some very specific thing. You can do your own threadpool which wont use the Io interface. But if one of the tasks in the threadpool wanted to read a file, I guess you'd have to pass in the blocking Io implementation.