Re:Open-sourcing gVisor, a sandboxed container runtime
by pcwalton on Wednesday May 02, 2018 @02:18PM
(#16979732)
Data races are not easy to "code review out". That is contrary to decades of experience. All you have to do in Go to get a race is to close over a for loop induction variable in a goroutine.
There is not a large difference between C and Go here. In fact, races might be easier in Go than in C, because it's easier for goroutines to close over mutable variables.
Re:Open-sourcing gVisor, a sandboxed container runtime
by staticassertion on Wednesday May 02, 2018 @02:41PM
(#16979939)
> That is contrary to decades of experience.
In languages like C and C++.
I haven't really seen this as a big problem in Go. I know of one vulnerability involving this, personally. I haven't gone looking though.
Regardless, I think there's a world of difference between C and Go when it comes to memory safety.
Re:Open-sourcing gVisor, a sandboxed container runtime
by pcwalton on Wednesday May 02, 2018 @03:03PM
(#16980145)
> I haven't really seen this as a big problem in Go.
Go certainly does have problems with data races all the time. Just Google for "golang data race": you'll find many blog posts explaining common data race gotchas in Go.
> Regardless, I think there's a world of difference between C and Go when it comes to memory safety.
Agreed.
But they're also generally easy to code-review out. There's definitely a huge difference between C and Go, regardless of this one caveat to Go's memory safety guarantees.
They aren't using single threaded Go from what I can see.