5 ms·
> which means that the memory will always be safe to use In another post [1], the author of the article claims that Go will not "tolerate unsafe memory access"
by brobinson 11y ago
> which means that the memory will always be safe to use
In another post [1], the author of the article claims that Go will not "tolerate unsafe memory access".
A reference to a variable could be sent across a channel and nil'd from the sending goroutine before being dereferenced in the recipient goroutine, causing a crash. Doesn't this invalidate the "safe memory" claims, or are concurrency-related memory issues not considered when making that claim?
[1] http://dave.cheney.net/2015/07/02/why-go-and-rust-are-not-competitors http://dave.cheney.net/2015/07/02/why-go-and-rust-are-not-co...
- dbaupp 11y agoDereferencing nil is not an unsafe memory access in Go, just like a null pointer exception in Java isn't unsafe. Both are well-defined operations (sure, they yield errors, but they do so with 100% reliability and complete control), they're not undefined behaviour like in C or C++. Unsafe memory accesses refers to things like accessing an array out-of-bounds, or reading from a pointer that has already been freed. (I suspect a data race could actually cause an array to be accessed out of bounds in Go, but I'm not sure.)
- brobinson 11y agoThanks for the clarification! What if instead of the sender goroutine setting the pointer to nil, the GC frees the object that the pointer was pointing to before the recipient goroutine reads it? Wouldn't that be considered "reading from a pointer that has already been freed"?
- ustolemyname 11y agoThat can't happen. The GC won't free the object until nothing references it, and in your proposed scenario either the channel or receiving goroutine will have a valid reference.