Skip to content

Conversation

@namse
Copy link
Contributor

@namse namse commented Jul 18, 2025

Replaced all uses of crossbeam::channel with std::sync::mpsc to reduce the dependency footprint.

Changes

  • Modified channel imports from crossbeam::channel::{Sender, Receiver} to std::sync::mpsc::{Sender, Receiver}
  • Changed crossbeam::channel::unbounded() to std::sync::mpsc::channel()
  • Removed crossbeam = "0.8" dependency from 8 Cargo.toml files
  • Removed pub extern crate crossbeam; from src/lib.rs
  • Updated doc comments to remove crossbeam mentions

As discussed in #828, crossbeam is only used for its channel implementation. Since std::sync::mpsc provides equivalent functionality for this use case, we can use the standard library instead.

Fixes #828

namse and others added 2 commits July 18, 2025 09:47
- Replace all uses of crossbeam::channel with std::sync::mpsc
- Remove crossbeam dependency from all Cargo.toml files
- Update documentation to remove crossbeam references
- Use std::sync::mpsc::channel() instead of crossbeam::channel::unbounded()

Fixes dimforge#828

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <[email protected]>
@sebcrozet sebcrozet merged commit f4b659e into dimforge:master Jul 24, 2025
8 checks passed
@sebcrozet
Copy link
Member

Thank you! I have tested it on wasm and confirm it’s working properly.

@namse namse deleted the replace-crossbeam-with-std-mpsc branch July 25, 2025 00:16
@Ptrskay3
Copy link

Ptrskay3 commented Jul 25, 2025

Hey!

I just want to mention that feature-wise std::sync::mpsc may be equivalent, but there is a difference. crossbeam::channel::Receiver implements Sync, but std::sync::mpsc::Receiver is !Sync, and this is a breaking change. This change is blocking our upgrade path (or requires a significant re-thinking of our current structure).

@sebcrozet
Copy link
Member

@Ptrskay3

Hey!

Thank you for your feedback, I didn’t realize that difference between the two!
Note that the ChannelEventCollector (which is what’s relying on the channel) is provided as a convenience, but is entirely optional. So you can easily reimplement it using crossbeam channels and implement the EventHandler trait:

/// A collision event handler that collects events into a channel.
pub struct ChannelEventCollector {
collision_event_sender: Sender<CollisionEvent>,
contact_force_event_sender: Sender<ContactForceEvent>,
}
impl ChannelEventCollector {
/// Initialize a new collision event handler from channel senders.
pub fn new(
collision_event_sender: Sender<CollisionEvent>,
contact_force_event_sender: Sender<ContactForceEvent>,
) -> Self {
Self {
collision_event_sender,
contact_force_event_sender,
}
}
}
impl EventHandler for ChannelEventCollector {
fn handle_collision_event(
&self,
_bodies: &RigidBodySet,
_colliders: &ColliderSet,
event: CollisionEvent,
_: Option<&ContactPair>,
) {
let _ = self.collision_event_sender.send(event);
}
fn handle_contact_force_event(
&self,
dt: Real,
_bodies: &RigidBodySet,
_colliders: &ColliderSet,
contact_pair: &ContactPair,
total_force_magnitude: Real,
) {
let result = ContactForceEvent::from_contact_pair(dt, contact_pair, total_force_magnitude);
let _ = self.contact_force_event_sender.send(result);
}
}

So, instead of re-thinking your current structure you can define your own EventHandler based on crossbeam channels, and use it anywhere you are currently using ChannelEventCollector.

Let me know if a custom implementation doesn’t work in your use-case.

@Ptrskay3
Copy link

Thanks for the quick response — I haven't looked into that part at all, just noticed the giant compiler errors from an axum handler and traced back to there. Implementing the EventHandler trait manually will definitely work. Sorry, I wasn't really familiar with that part.

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.

Consider using std::sync::mpsc instead of crossbeam-channel

3 participants