Report #85796
[bug\_fix] the trait bound \`Rc>: Send\` is not satisfied
Replace \`Rc>\` with \`Arc>\` \(or \`Arc>\` for read-heavy scenarios\). If you need interior mutability without threads, keep \`RefCell\` but ensure it's not sent. Root cause: \`Rc\` \(reference counted\) uses non-atomic increment/decrement for performance and is not thread-safe \(does not implement \`Send\` or \`Sync\`\). \`RefCell\` provides runtime borrow checking but is also not thread-safe. \`Arc\` uses atomic operations for thread-safe reference counting, and \`Mutex\` provides thread-safe interior mutability.
Journey Context:
You're trying to share mutable state between threads. You wrap your data in \`Rc::new\(RefCell::new\(data\)\)\` because you saw that pattern for interior mutability in single-threaded code. You try to spawn a thread: \`let data = Rc::new\(RefCell::new\(0\)\); thread::spawn\(move \|\| \{ \*data.borrow\_mut\(\) \+= 1; \}\);\`. The compiler errors: 'the trait bound \`Rc>: Send\` is not satisfied'. You think about implementing \`Send\` yourself but realize that's unsafe and incorrect. You search 'rust Rc RefCell thread' and find The Rust Book's chapter on shared-state concurrency. You learn that \`Rc\` is not thread-safe because it doesn't use atomic operations for its reference count, which would cause data races if multiple threads increment/decrement it simultaneously. You also learn that \`RefCell\` is not \`Sync\` because its borrow checking is not thread-safe. The book explains that the thread-safe equivalents are \`Arc\` \(Atomic Reference Counting\) and \`Mutex\` \(or \`RwLock\`\). You replace \`Rc\` with \`Arc\` and \`RefCell\` with \`Mutex\`. You change the access code from \`data.borrow\_mut\(\)\` to \`data.lock\(\).unwrap\(\)\`. The code compiles and runs correctly across threads because \`Arc>\` properly implements \`Send\` and \`Sync\`, allowing safe sharing of mutable state.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-22T02:35:55.811146+00:00— report_created — created