Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bugs You'll Probably Only Have in Rust

gankro.github.io

Post reply on HN
Print view View original

71–80 of 91 posts

Re: Bugs You'll Probably Only Have in Rust

#71

Post by vitalyd »

Manishearth wrote: post #69
vitalyd wrote: post #64

Earlier quoted context omitted.

Right, but my question isn't about T itself, but rather how it's published to another thread. The example I gave is of a plain struct with no atomics or any other synchronization types internally. A &T is auto-derived to be Sync. But, if a publisher incorrectly publishes this reference, the other thread may see a partially initialized value.

There are three ways of sharing data across threads. One is by sharing the data with the thread when it is spawned via a closure. Spawning will fence. No problem there. The second is to use a good 'ol Sender/Receiver channel pair. These are effectively a shared ring buffer that you can push to and pop from. They also have a fence somewhere. Finally, you can stick your data into a mutex shared between threads (and let…

Yeah, I understand and what I expected to be the answer. My point is that when people talk about Sync not allowing data races, there's the asterisk attached to that statement. That footnote is that publishing code, which is completely separate from the type itself, needs to uphold its responsibility. Unsafe code is usually discussed in light of raw pointers and more generally raw memory ops, but I rarely see this aspect mentioned.

Re: Bugs You'll Probably Only Have in Rust

#72

Post by vitalyd »

dbaupp wrote: post #68
vitalyd wrote: post #65

Earlier quoted context omitted.

I think it's fair to question a type being auto-derived to be Sync if only individual fields are Sync. It may lead to improper sharing of a reference to this value where threadsafety across fields is needed. That would be a bug, yes, but compiler never made the author pause to consider putting Sync there explicitly (and presumably thinking this through). So that "linting" aspect that's applied to, e.g., *mut T is not…

I'm not entirely sure what you mean. The compiler does make the author pause: dangerous types like `*mut T and `UnsafeCell ` are not Sync, so types containing them are also not automatically Sync. In any case, Rust only guarantees no memory unsafety (requiring no data races). It tries to help with other things, like cleaning up resources via destructors, but these are "best-effort" rather than guarantees. The only wa…

I suppose my point was that auto-deriving Sync may not have been such a great idea :). I understand the rationale for it but it does open up traps for people to fall into.

Re: Bugs You'll Probably Only Have in Rust

#73

Post by burntsushi »

vitalyd wrote: post #71
Manishearth wrote: post #69

Earlier quoted context omitted.

There are three ways of sharing data across threads. One is by sharing the data with the thread when it is spawned via a closure. Spawning will fence. No problem there. The second is to use a good 'ol Sender/Receiver channel pair. These are effectively a shared ring buffer that you can push to and pop from. They also have a fence somewhere. Finally, you can stick your data into a mutex shared between threads (and let…

Yeah, I understand and what I expected to be the answer. My point is that when people talk about Sync not allowing data races, there's the asterisk attached to that statement. That footnote is that publishing code, which is completely separate from the type itself, needs to uphold its responsibility. Unsafe code is usually discussed in light of raw pointers and more generally raw memory ops, but I rarely see this asp…

My point above was subtle but important: the asterisk you're mentioning here is not specific to Sync. This is true of all safety guarantees in Rust. unsafe code must uphold the invariants that safe code will rely on, otherwise it's buggy. For example, if the implementation of `Vec` accidentally got its internal `length` out-of-sync with the data on the heap, then nothing bad in and of itself necessarily happens immediately. The bad thing only happens the next time you try to do something with the `Vec`, which will be in safe code.

The safety of things in Rust is built on abstraction. If abstraction gets something wrong in its `unsafe` details, then there is a bug there. In other words, the asterisk you're mentioning is "You can trust that safe Rust is free of memory safety, unless there are bugs." I feel like that's discussed and acknowledged quite a bit.

> Unsafe code is usually discussed in light of raw pointers and more generally raw memory ops, but I rarely see this aspect mentioned.

I guess I don't see a difference. The safeness of Rust code depends on the correct use of `unsafe`, and this applies to everything, not just Sync.

This idea of `unsafe` being "trusted code" is one of the first things that the Rustonomicon covers: https://doc.rust-lang.org/nomicon/safe-unsafe-meaning.html

Re: Bugs You'll Probably Only Have in Rust

#74

Post by 121982312 »

kbenson wrote: post #26
Animats wrote: post #23

Earlier quoted context omitted.

Outside of foreign functions, "unsafe" is used mostly for (sometimes premature) optimization. "Vec" needs "unsafe" because Rust can't talk about a partially initialized array. But "Vec" isn't very complicated. Maps are very complicated, and written as unsafe code. They could been written using "Vec" for storage, but they're not; they're at the raw storage level. That's a possibly premature optimization. There's a lot…

> (I've complained about this in the past, pointing to places There's a Rust fanboy who usually replies, without citing any references, denying everything. The usual excuses are 1) nobody really uses unsafe crate X much, 2) the crates fanboy is using contain less unsafe code than I'm finding.) While I've actually seen you point this out multiple times here, and seen the response you describe, I can't help but feel yo…

The aggressive Rust evangelism is counterproductive, too.

Every time I want to look at Rust, a new thread with vicious fanboyism comes up, turning me away from the language.

I just want a new C-like language. I don't want to be part of a cult, call packages "crates" and other nonsense.

Re: Bugs You'll Probably Only Have in Rust

#75

Post by vitalyd »

burntsushi wrote: post #73
vitalyd wrote: post #71

Earlier quoted context omitted.

Yeah, I understand and what I expected to be the answer. My point is that when people talk about Sync not allowing data races, there's the asterisk attached to that statement. That footnote is that publishing code, which is completely separate from the type itself, needs to uphold its responsibility. Unsafe code is usually discussed in light of raw pointers and more generally raw memory ops, but I rarely see this asp…

My point above was subtle but important: the asterisk you're mentioning here is not specific to Sync. This is true of all safety guarantees in Rust. unsafe code must uphold the invariants that safe code will rely on, otherwise it's buggy. For example, if the implementation of `Vec ` accidentally got its internal `length` out-of-sync with the data on the heap, then nothing bad in and of itself necessarily happens imme…

> I guess I don't see the difference

At a high and general level, yeah, it's all "unsafe". But, most conversations about unsafe don't talk about this aspect. So while what you say is true, I'm merely pointing out that this concurrency aspect doesn't seem to be mentioned much. And while it's implied at a high level, I think it's worth mentioning.

Basically, there's no issue - I just think this should be called out more when concurrency is discussed.

Re: Bugs You'll Probably Only Have in Rust

#76

Post by lightedman »

And this is why I stick with ASM - I don't have to rely upon everyone else not screwing the pooch when it comes to them developing a language - I just talk straight to the computer, nothing gets lost in translation, my programs are 200x smaller and 400x faster than anything written in Rust.

2D Second Life clone, with full programming capability with built-in database - 2 megabytes. Solid ASM. Rust can't even come close, and never will.

Re: Bugs You'll Probably Only Have in Rust

#77

Post by runeks »

lightedman wrote: post #76

And this is why I stick with ASM - I don't have to rely upon everyone else not screwing the pooch when it comes to them developing a language - I just talk straight to the computer, nothing gets lost in translation, my programs are 200x smaller and 400x faster than anything written in Rust. 2D Second Life clone, with full programming capability with built-in database - 2 megabytes. Solid ASM. Rust can't even come clo…

> [..] my programs are 200x smaller and 400x faster than anything written in Rust.

And take 100x longer to develop :)

Re: Bugs You'll Probably Only Have in Rust

#78

Post by mcguire »

vitalyd wrote: post #51
mcguire wrote: post #43

" The bug was a missing annotation, and the result was that users of Rust's stdlib could compile some incorrect programs that violated memory safety. " IIUC, technically, the bug was a missing implementation of a trait and the result was a data race (which I (weirdly, maybe) don't think of as memory safety). In other words, TL;DR: magic is neat, except that sometimes it really sucks. I may have misunderstood Ralf's b…

> I may have misunderstood Ralf's bug. Is it really the case that MutexGuard was seen as Sync if T was Send, rather that Sync? Wouldn't that be a bigger problem than just the case of MutexGuard? So T: Sync if &T: Send. MutexGuard internally contains a &Mutex (and Poison, but that's irrelevant here). T was Cell . If you follow the rabbit hole, you'll net out that T was Send, and therefore MutexGuard was Sync.

Ah! I wasn't following the references close enough.

Re: Bugs You'll Probably Only Have in Rust

#79

Post by burntsushi »

vitalyd wrote: post #75
burntsushi wrote: post #73

Earlier quoted context omitted.

My point above was subtle but important: the asterisk you're mentioning here is not specific to Sync. This is true of all safety guarantees in Rust. unsafe code must uphold the invariants that safe code will rely on, otherwise it's buggy. For example, if the implementation of `Vec ` accidentally got its internal `length` out-of-sync with the data on the heap, then nothing bad in and of itself necessarily happens imme…

> I guess I don't see the difference At a high and general level, yeah, it's all "unsafe". But, most conversations about unsafe don't talk about this aspect. So while what you say is true, I'm merely pointing out that this concurrency aspect doesn't seem to be mentioned much. And while it's implied at a high level, I think it's worth mentioning. Basically, there's no issue - I just think this should be called out mor…

Could you say more about why you see concurrency as a special thing to call out? I'm genuinely curious so that I can adapt how I explain this stuff in the future. It would help to understand the distinction you are seeing that I am not. :-)

Re: Bugs You'll Probably Only Have in Rust

#80

Post by Manishearth »

vitalyd wrote: post #75
burntsushi wrote: post #73

Earlier quoted context omitted.

My point above was subtle but important: the asterisk you're mentioning here is not specific to Sync. This is true of all safety guarantees in Rust. unsafe code must uphold the invariants that safe code will rely on, otherwise it's buggy. For example, if the implementation of `Vec ` accidentally got its internal `length` out-of-sync with the data on the heap, then nothing bad in and of itself necessarily happens imme…

> I guess I don't see the difference At a high and general level, yeah, it's all "unsafe". But, most conversations about unsafe don't talk about this aspect. So while what you say is true, I'm merely pointing out that this concurrency aspect doesn't seem to be mentioned much. And while it's implied at a high level, I think it's worth mentioning. Basically, there's no issue - I just think this should be called out mor…

You need raw pointer ops (or, well, dealing with UnsafeCell, which does raw pointer stuff), or syscalls for these too.

Concurrency is not special here. There are all kinds of invariants unsafe code might be required to uphold. So yeah, we could mention concurrency, but then we could also mention UTF8, noalias, initialization, the vector length invariant, the HashMap robin hood invariant, various BTreeMap invariants, etc etc. "Make sure you have fences" is just another semi-specific invariant.

I disagree that "most conversations about unsafe don't talk about this aspect", compartmentalizing unsafe invariants is a major part of these discussions (it's like the first chapter of the nomicon, even)

Post reply on HN