Skip to content

Conversation

@simonrw
Copy link
Owner

@simonrw simonrw commented Dec 31, 2025

This plan outlines a complete strategy for migrating the transport and
debugger crates from sync-based concurrency to async-based concurrency.

Key highlights:

  • Async transport layer with native timeout and cancellation support
  • Async debugger API with better resource management
  • Integration patterns for both egui and iced UI frameworks
  • Phased migration strategy to minimize risk
  • Detailed code examples and architecture diagrams

The async migration will provide:

  • Better support for timeouts and cancellation
  • Improved resource utilization (tasks vs threads)
  • More composable APIs
  • Easier integration with modern Rust async ecosystem

Timeline: 13-20 days estimated for full migration
Recommendation: Use tokio runtime with incremental rollout

This plan outlines a complete strategy for migrating the transport and
debugger crates from sync-based concurrency to async-based concurrency.

Key highlights:
- Async transport layer with native timeout and cancellation support
- Async debugger API with better resource management
- Integration patterns for both egui and iced UI frameworks
- Phased migration strategy to minimize risk
- Detailed code examples and architecture diagrams

The async migration will provide:
- Better support for timeouts and cancellation
- Improved resource utilization (tasks vs threads)
- More composable APIs
- Easier integration with modern Rust async ecosystem

Timeline: 13-20 days estimated for full migration
Recommendation: Use tokio runtime with incremental rollout
Updated the plan to focus exclusively on tokio rather than being
runtime-agnostic. This simplifies the implementation significantly.

Changes:
- Replace async_lock with tokio::sync primitives (Mutex, RwLock)
- Replace async_broadcast with tokio::sync::broadcast
- Update egui bridge to use tokio::sync::mpsc for commands
- Simplify dependencies (only tokio, tokio-util, async-trait)
- Update all code examples to use tokio primitives
- Streamline "Runtime Considerations" section
- Emphasize tokio's superior tooling and ecosystem

This aligns with the user's preference to commit to tokio as the
async runtime rather than maintaining runtime abstraction.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants