-
-
Notifications
You must be signed in to change notification settings - Fork 82
Using Mun in a threaded environment #299
Copy link
Copy link
Closed
Labels
pri: intermediateAn issue resulting in non-critical functionality loss and no significant effect on usabilityAn issue resulting in non-critical functionality loss and no significant effect on usabilitytype: featNew feature or requestNew feature or request
Milestone
Metadata
Metadata
Assignees
Labels
pri: intermediateAn issue resulting in non-critical functionality loss and no significant effect on usabilityAn issue resulting in non-critical functionality loss and no significant effect on usabilitytype: featNew feature or requestNew feature or request
The
mun_runtime::Runtimeis notSyncnorSendsince theRuntimeBuilder::spawnfunction returns aRc<RefCell<Runtime>>. This makes it hard to use in other programs that make use of threads. The reason we wrap theRuntimein anRcis because the runtime (or better yet, the memory model) is not thread safe. Wrapping theRuntimein a mutex will also not work because the memory model is shared between other structs (likeStructRef). Sending theRuntimeto a thread and doing modifications while also accessing aStructReffrom another thread will cause threading issues.We've already talked about this a lot. We currently have no proper plan to support multithreading. However, our current solution is also not very ergonomic. I propose we implement a blocking solution that still doesnt do multithreading of the runtime but does allow the runtime and derived data to be shared across threads. In a later version we can then add proper multithreading hopefully using the same API we design now.
A straighforward solution is to wrap all memory modifying operations inside a mutex. This will block any operation performed by other threads but will enable the use of the Runtime and derived data to be send to different threads.
Curious to your thoughts!