Refactor shuttle into modular crates
- Dominant language
- Rust
- Stars
- 1.1k
- Forks
- 59
- Avg merge
- 4d 2h
- Merged PRs (30d)
- 15
Description
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`](https://crates.io/crates/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):
* **shuttle-core**
* trait `Scheduler`
* do we need `dfs` here too, for running tests for `shuttle-core` ?
* Runtime, execution state, vector clocks
* a core primitive that all other primitives (like `Mutex`, `mpsc` channels etc) can be built on top of
* currently, this is `BatchSemaphore`, but we should consider making an even more foundational primitive that is smaller, easier to maintain, and supports building things like `atomic-wait`
* **shuttle-schedulers**
* put all the specific schedulers here (Random, Pct, URW, ...)
* **shuttle-sync**
* all the `std::sync` replacement primitives
* specific libraries that need Shuttle replacements, following the `shuttle-tokio` pattern designed by @sarsko
* tokio, tokio-stream (#238)
* parking-lot (#232)
* ...
* main **shuttle** entry point
* re-export for convenience and backward compatibility
Contributor guide
Research direction
No files or tests are named. Start by reviewing the existing crate layout and the shuttle-tokio and shuttle-parking_lot work referenced in #238 and #232, then map the proposed shuttle-core, shuttle-schedulers, shuttle-sync, library-specific crates, and main shuttle entry point. Done means the responsibilities are separated while the main entry point preserves backward compatibility.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- developer-experience, testing
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100