You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the README.md of the repo, it says that the lib only supports single-threaded applications, but given that the inner type of a Gc pointer now requires Send and Sync, I wanted to check if this was still the case.
The text was updated successfully, but these errors were encountered:
Good question. Multi-threaded Rust is still not supported, no. Send and Sync are a requirement for single-threaded applications. This is because the collector finalizes values off the main thread. Consider the following (untested) example:
structS{inner:Rc<String>}implDropforS{fndrop(&mutself){// deref a non-send, non-sync field. This must be done from the same thread.println("Hello {}",self.inner);}}fnmain(){let rc = Rc::new(String::from("Hello World"));let s = Gc::new(Rc::clone(rc));// 1. gc collection happens, `s` is finalized off-thread, calling S::drop. // 2. The drop impl deref's a `Rc<String>` off the main thread. This is UB.}
This example is somewhat contrived, but it's there to illustrate that the Send + Sync constraint exists because of how values are Droped by the collector.
For multi-threading support, we still need a way to intercept pthread_create calls in order to register each thread's call stack with the collector. Until this is in place it will kinda-sorta work, but it is unsound because eventually the GC will miss a pointer from a root on a non-registered thread's call stack.
In the README.md of the repo, it says that the lib only supports single-threaded applications, but given that the inner type of a Gc pointer now requires
Send
andSync
, I wanted to check if this was still the case.The text was updated successfully, but these errors were encountered: