We should refactor shuttle into a modular structure. Currently, the core runtime, schedulers, standard library primitives, and test utilities are all bundled together. Separating these would make it easier to add support for new libraries (like tokio and parking_lot), improve maintainability, and provide a minimal core focused on tracking dependencies via vector clocks and exposing foundational primitives for building custom synchronization constructs (like atomic-wait requested in #248 ).
We've already started doing this with shuttle-tokio (#238) and shuttle-parking_lot (#232)
Here's a proposed crate structure we could consider (credit due to @sarsko and @Aurel300 who came up with most of this):
We should refactor shuttle into a modular structure. Currently, the core runtime, schedulers, standard library primitives, and test utilities are all bundled together. Separating these would make it easier to add support for new libraries (like tokio and parking_lot), improve maintainability, and provide a minimal core focused on tracking dependencies via vector clocks and exposing foundational primitives for building custom synchronization constructs (like
atomic-waitrequested in #248 ).We've already started doing this with shuttle-tokio (#238) and shuttle-parking_lot (#232)
Here's a proposed crate structure we could consider (credit due to @sarsko and @Aurel300 who came up with most of this):
shuttle-core
Schedulerdfshere too, for running tests forshuttle-core?Mutex,mpscchannels etc) can be built on top ofBatchSemaphore, but we should consider making an even more foundational primitive that is smaller, easier to maintain, and supports building things likeatomic-waitshuttle-schedulers
shuttle-sync
std::syncreplacement primitivesspecific libraries that need Shuttle replacements, following the
shuttle-tokiopattern designed by @sarskomain shuttle entry point