Repository navigation
Remove unwrap_shared_mutable_state #4436
Description
We're about to start rewriting the runtime in Rust and need concurrency primitives, particulary atomic reference counting for schedulers, etc. This one feature makes some complicated calls into the runtime, making most of our primitives unusable for this task.
Activity
bblum commentedon Jan 11, 2013
Removing unwrap will mean that once data is put into an ARC, MutexARC, or RWARC, it can never be owned again short of a deep copy.
I don't understand the issue here at all, though. It doesn't use any rustrt calls, only intrinsics (transmute, forget, cmpxchg). What's the problem?
brson commentedon Jan 11, 2013
That's fine with me. I don't have any use cases yet where I need to stop atomically reference counting something.
It interacts with the runtime because it uses pipes, which must be able to yield, resume, etc.,
task::killable,task::failing.bblum commentedon Jan 11, 2013
Oh, I see, you're saying there could be a circular functionality dependency. Why not just abstain from using it in the runtime's use cases, leaving it in for higher-level applications?
brson commentedon Feb 4, 2013
Mostly because that's not such a clean design. I'll also note that unwrap has bugs: #4689
bblum commentedon Feb 4, 2013
I dunno. I think unwrap is a useful enough extension to the primitive (it enables a quick fork-many/join-many pattern) to warrant keeping.
As for the bug... ouch. I'll try to have a look at it soon. Hopefully just a bug in the test case.
bblum commentedon Feb 28, 2013
Given that #4689 is fixed, I'm gonna vote for WONTFIXing this.
core: Remove unwrap_shared_mutable_state. rust-lang#4436
auto merge of #5176 : brson/rust/unwrap_shared_mutable_state, r=nikom…
brson commentedon Mar 1, 2013
I've done this against your objection, @bblum. Sorry.
Merge pull request rust-lang#4436 from rust-lang/rustup-2025-07-02
Merge rust-lang#4436