Hi Lee, 2013/4/27 Lee Braiden <leebr...@gmail.com>: > > But we're not talking about creating a new task for every io operation as > the io module's usual under-the-hood strategy, surely? > > It seems to me that, by default, what we'd want is a sync api which under > the hood, creates one task per drive accessed, or maybe max(drives_in_use, > number_of_cores). I think the OS will make them async with the drive > hardware anyway, though, so number_of_cores doesn't matter.
This is similar to what GLib/GIO designers have achieved (and I am writing Rust bindings for it, so hopefully everybody can soon try that async I/O stack in Rust, too). Client operations are dispatched under the hood to a thread pool, and an implementation of a complex operation can choose to perform smaller steps synchronously in a task to avoid the async overhead for each constituent step. The client can pass a thread-safe cancellation handle to be able to cancel the whole operation on every step (thankfully not in the finicky POSIX way), with the theoretical granularity of every blocking call to the OS or a backend. In hope this information is useful, Mikhail _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
