The crates compio-runtime, compio-fs, compio-net, and compio-process depends on the driver directly, while users usually don't. The low-level code breaks faster than the high-level one. I propose hiding the driver from the public interface of the monocrate.
A new trait will be introduced in compio-driver:
pub trait RuntimeExt {
fn with_driver<R>(&self, f: impl FnOnce(&Proactor) -> R) -> R;
fn with_driver_mut<R>(&self, f: impl FnOnce(&mut Proactor) -> R) -> R;
fn driver_type(&self) -> DriverType {
self.with_driver(|p| p.driver_type())
}
}The types Submit* could even be decoupled from the runtime as they only depends on the proactor. If we want a complete decoupling, we could add a trait for Proactor.
compio_runtime::Runtime will implement RuntimeExt, but users will not be able to use it until they pull compio-driver in explicitly. Then it will be safe to introduce breaking changes to compio-driver, because the high-level APIs will depend on a different driver. submit methods will break, but it's because the user is trying to use a low-level OpCode, whose stability is not guarenteed by the high-level APIs.
The crates
compio-runtime,compio-fs,compio-net, andcompio-processdepends on the driver directly, while users usually don't. The low-level code breaks faster than the high-level one. I propose hiding the driver from the public interface of the monocrate.A new trait will be introduced in
compio-driver:The types
Submit*could even be decoupled from the runtime as they only depends on the proactor. If we want a complete decoupling, we could add a trait forProactor.compio_runtime::Runtimewill implementRuntimeExt, but users will not be able to use it until they pullcompio-driverin explicitly. Then it will be safe to introduce breaking changes tocompio-driver, because the high-level APIs will depend on a different driver.submitmethods will break, but it's because the user is trying to use a low-levelOpCode, whose stability is not guarenteed by the high-level APIs.