6 ms·
Build your own async primitive
- rav 6y ago> Values that are forgotten without being dropped can leak resources or even cause undefined behavior! I thought that Rust had given up on considering mem::forget to be undefined behavior? I think this sentence should be softened to just say "cause other unwanted behavior", since "undefined behavior" is such a precise concept.
- saghm 6y agoYes, you're correct. From the documentation on std::mem::forget[1]: "forget is not marked as unsafe, because Rust's safety guarantees do not include a guarantee that destructors will always run. For example, a program can create a reference cycle using Rc, or call process::exit to exit without running destructors. Thus, allowing mem::forget from safe code does not fundamentally change Rust's safety guarantees. That said, leaking resources such as memory or I/O objects is usually undesirable. The need comes up in some specialized use cases for FFI or unsafe code, but even then, ManuallyDrop is typically preferred. Because forgetting a value is allowed, any unsafe code you write must allow for this possibility. You cannot return a value and expect that the caller will necessarily run the value's destructor." [1]: https://doc.rust-lang.org/std/mem/fn.forget.html#safety https://doc.rust-lang.org/std/mem/fn.forget.html#safety
- kzrdude 6y agoIt hasn't officially been formulated this way, but whatever owns a value will have the power to decide if its destructor should run or not.
- jganetsk 6y agodeleted
- Arnavion 6y ago>The comment for the take method claims that put and take can be called be concurrently with each other. But both call get() on an UnsafeCell. They can be called concurrently with each other, but the call to `UnsafeCell::get()` is guarded by an acquire-release latch for precisely that reason. This is already explained in the article. >I'm scratching my head on the syntax. There is no read() method on MaybeUninit. Also, the type passed to the write() method is wrong. I need to clone this and see if I can compile this. read() and write() are functions of `*mut T`, which is what is returned by `UnsafeCell::get()`
- jganetsk 6y agoI don't know that synchronizing with acquire-release is enough to make LLVM happy in this case. Mutable references are tagged with the LLVM noalias attribute. Rust language folks are very adamant about how wrong it is to end up with multiple aliases tagged with noalias. This is playing with fire.
- Arnavion 6y agoThere are no multiple aliases in the code presented in the blog post.
- jganetsk 6y agoOk you are right.
- steveklabnik 6y agoAlso UnsafeCell’s purpose in life is to make sure noalias is removed where appropriate.
- jganetsk 6y agoCan you explain that more? Because the requirement I pasted about having unique aliases does come from the UnsafeCell documentation. My understanding is that &mut still needs to be a unique alias even when it comes from an UnsafeCell.