Tracking issue for `as_unsafe_cell` stabilization

[aturon]

The Cell::as_unsafe_cell and RefCell::as_unsafe_cell methods return a reference to the underlying UnsafeCell in both cases.

It's not clear what the use cases are for these methods and whether they can be achieved in some alternative way. If you are using these methods, please leave a comment with your use case.

[aturon]

cc @kmcallister, I think you may have employed these methods in Servo?

[jdm]

We do use the methods for RefCell: http://mxr.mozilla.org/servo/search?string=as_unsafe_cell . We appear to do so in cases where a GC could occur at virtually any time and the there may be outstanding borrows of fields that need to be traced. Similarly, it gets used for cases when we want to ensure certain resources are cleaned up if a panic occurs but there may be outstanding borrows that would prevent doing this through the stable, safe interface. Finally, we also use this for parallel code, but @pcwalton will need to explain the motivation there I think.

[alexcrichton]

Nominating for resolution in 1.5

[alexcrichton]

The libs team decided to not move this issue to FCP for this cycle.

@jdm, can you clarify something for us? It looks like this method is used to subvert any active borrows of a RefCell during tracing, but isn't this fundamentally unsafe? How can accessing a RefCell while it's borrowed mutably elsewhere be safe?

[jdm]

When you describe it like that, it does sound pretty incorrect.

[aturon]

@jdm @alexcrichton If this is done during a tracing phase in which the thread owning the RefCell (the "mutator" in GC parlance) is paused, it may be OK. (IMO, any GC has to have some interaction with RefCell that subverts the borrow tracking.)

[alexcrichton]

I'd be a little worried in terms of optimizations here if we told LLVM something along the lines of "you have a mutable pointer, make any assumption you like knowing that no one else will ever have this pointer unless you hand it to them". That sort of contract would be violated where even if the mutator were paused an optimization may still trigger undefined behavior.

Concretely, if the source looked like:

let slot = a.borrow_mut();
println!("{}", slot.foo);
function();
println!("{}", slot.foo);

It seems like a valid optimization that the value loaded from slot.foo doesn't need to be reloaded across the call to function. The function has mutable access to the contents, so it's "guaranteed" that no one else has access to the pointer, but if some sort of mutation or something happened then badness may arise.

Again though, this is all very hypothetical, I'd certainly be willing to believe that the exact situation here actually works out due to some combination of some actions or whatnot.

[jdm]

Note that there should not be any mutation taking place in function in Servo's case. The use of unsafe cells like this is simply to avoid the difficulty of calling into any SM API that could trigger a GC while a mutable borrow is outstanding.

[seanmonstar]

This function is unsafe because UnsafeCell's field is public.

It seems that the unsafe could be removed from this method, since you can no longer access the UnsafeCell's value directly.

[Columbus240]

I'm using this function to check if two RefCells point to the same memory location because there's no other way to do this in Rust. Could be stabilized in my opinion.