On Tue, Jun 6, 2023 at 4:31 PM Caleb Spare <cesp...@gmail.com> wrote: > > Can someone explain why the following test shows a race between the > indicated lines? > > https://github.com/cespare/misc/blob/b2e201dfbe36504c88e521e02bc5d8fbb04a4532/httprace/httprace_test.go#L12-L43 > > The race seems to be triggered by the very last line of the test: > > get(client1) > > If I comment that out, then the race detector doesn't complain. But > then it seems that a read of a variable which happens before an HTTP > request which causes a write of the variable ultimately races with the > original read, which doesn't make sense. > > It seems like a false positive (perhaps the race detector doesn't > understand causality across a TCP connection?), but so far I've never > seen the race detector have a false positive, so I think I must be > missing something. > > I wrote a slightly simpler test (see TestHTTPRace2 right below in the > same file) which tries to make the race happen using a regular HTTP > handler and a single client and the race detector doesn't complain.
I haven't looked at your case in full detail. But it's true that the race detector does not know anything about TCP connections. In general it only knows about the cases described in the Go memory model (https://go.dev/ref/mem). It does seem that your code is only avoiding a race because the TCP read serializes the server goroutine and the main client goroutine. The race detector doesn't know anything about that. Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVwxW%2BMk7Z4Dybiri4FSFt8bA9mPMCQiadxtCKKjp%2BYgQ%40mail.gmail.com.
