Nphysics+specs: CollisionWorld doesn't implement Send

ncollide
1

I’m trying to write a game in Rust. Since ncollision and specs seemed popular and useful, I’m trying to use them.

However, since specs support multithreading, it requires resources used with it to implement Send, which CollisionWorld does not do.

Has anyone tried using CollisionWorld in specs at all, and how did they get around this issue?

I haven’t found much on Google:

  • This reddit thread mentions the issue in a PS but doesn’t mention a solution.
  • Another reddit thread: r/rust/comments/6qmbxg/hey_rustaceans_got_an_easy_question_ask_here/dl6j5jd/ mentions trying to work around it with Rc, but is mostly useless since Rcs don’t have anything to do with threading.
  • This post on this forum explains why CollisionWorld does not implement Send: because the callbacks on the event handlers need to run on the same thread they were created on. I don’t plan on using event handlers (I think I can get the same information by filtering the results of the contacts method).
2

Sorry for the very late answer, I don’t have a go-to solution but just so you know, nphysics will become much more easily integrable with specs in a couple of months. You can follow this work-in-progress pull request that address this issue. More details on the upcoming features can be foud on this post.

3

Thanks for the response; I’m glad that it’s being addressed.

I’ll share what I’ve done to try and work around it in specs, for future readers:

First, the system objects themselves don’t need to implement Send, so you can have thread-unsafe state in them, such as the collision world.

Second, the actual components in specs don’t have to implement Send, but their storage does, which usually necessitates the components implementing Send. What I ended up doing was making a wrapper storage implementation that unsafe impl's Send and Sync, and checks if the current thread is the same thread it was created on in all of its methods. It’s kindof a hack, but it seems to get the job done.

Both the workarounds of course mean you can’t use multithreading with the particular system (use RunOn instead).