WARNING: DATA RACE
Read at 0x00c42008a220 by main goroutine:
Previous write at 0x00c42008a220 by goroutine 7:
Goroutine 7 (finished) created at:
2017/10/04 16:48:53 1
Found 1 data race(s)
exit status 66
The text was updated successfully, but these errors were encountered:
I think you may be asking too much of the race detector. There is no obvious reason that the two different network connections are related. I mean, sure, they are, but only if you know that the Dial that created one matches the Accept that created the other. Only when you know that can you see that the Close of one affects the Read of the other.
@ianlancetaylor Does that apply to any causal connection through a network connection (for example using an httptest.Server and relying on being able to read variables after an HTTP request has replied) ?
Since c.Close() will call into the kernel, I don't think any plausible Go compiler could move the x++ across the call. Similarly, I think the x++ must be published. I think that any Go implementation must assume that the kernel may cause a happens-before relationship to be created. It's true that this is not in the memory spec, but in general Go is not trying to trick the programmer.
Ultimately any system call can synchronize with any other system call (e.g. create a file, another process notices that the dir becomes non-empty and send us a signal, so now creation of the file is somehow synchronized with arrival of the signal). But synchronizing everything with everything has a substantial negative effect in that it masks real data races.
To summarize: I don't see anything simple that we could do for Go to solve the problem. If we are talking about tests, I would suggest to add a separate chan that notifies about completion of handling of request/connection.