The raw fibers API as exposed by the fibers crate is potentially very unsafe because it allows smuggling !Send types between threads. While this technically violates Rust's type system, in practice we find that for most !Send types it doesn't actually violate their safety requirements. This is because most of these types are only unsafe if they are concurrently accessed from multiple threads (e.g. Rc<T> is only unsafe if two are sent two different threads, &RefCell<T> is only unsafe if sent to multiple threads at once, etc.). While the fibers API allows for !Send types to be smuggled between threads, it guarantees that those types are only ever in one thread at a time.
As a result, the only unsafety arises for types that have an actual thread affinity, like MutexGuard<T>. Often times these are system resources that have an opinion about which threads they can be accessed from. In the example of MutexGuard<T>, locking a mutex on one thread and then unlocking it won't work, leaving the mutex in a locked state, which leaves to deadlocks. That particular case doesn't lead to memory unsafety, but it's possible that there are other cases that will.
We need to get more data on what is safe to do with fibers and what isn't, and discuss with the Rust team/community what can be done to get the compiler to catch fiber-unsafe code.
The raw fibers API as exposed by the fibers crate is potentially very unsafe because it allows smuggling
!Sendtypes between threads. While this technically violates Rust's type system, in practice we find that for most!Sendtypes it doesn't actually violate their safety requirements. This is because most of these types are only unsafe if they are concurrently accessed from multiple threads (e.g.Rc<T>is only unsafe if two are sent two different threads,&RefCell<T>is only unsafe if sent to multiple threads at once, etc.). While the fibers API allows for!Sendtypes to be smuggled between threads, it guarantees that those types are only ever in one thread at a time.As a result, the only unsafety arises for types that have an actual thread affinity, like
MutexGuard<T>. Often times these are system resources that have an opinion about which threads they can be accessed from. In the example ofMutexGuard<T>, locking a mutex on one thread and then unlocking it won't work, leaving the mutex in a locked state, which leaves to deadlocks. That particular case doesn't lead to memory unsafety, but it's possible that there are other cases that will.We need to get more data on what is safe to do with fibers and what isn't, and discuss with the Rust team/community what can be done to get the compiler to catch fiber-unsafe code.