On Wed, Jun 7, 2023 at 2:19 PM Sven Anderson <s...@redhat.com> wrote:
> > > Caleb Spare <cesp...@gmail.com> schrieb am Mi. 7. Juni 2023 um 19:22: > >> On Wed, Jun 7, 2023 at 2:33 AM Sven Anderson <s...@redhat.com> wrote: >> > >> > That’s not only a read/write race, it’s also a write/write race. Every >> request to the server creates a new Go routine that might increment >> newConns in parallel, so it may get corrupted. Same for lines 39/40. >> > >> > You might claim, that for infrastructural reasons, there can be no >> concurrent requests to your server, but that would just mean that the race >> is not triggered, it’s there nevertheless. >> >> The race detector reports on races that actually happened, not races >> that could happen. >> > > A race condition is a condition, not an event, so I think „happened“ is > not correct, but maybe someone who knows the heuristics of the race > detector better can clear that up. > The race detector reports when shared memory is accessed concurrently from multiple goroutines. So it detects when a memory race happens. In this case however, what is reported is a concurrent write-after-read. Is that really a memory race? > > And why would it matter then if it understands the causalities of TCP? One > must be incorrect: Either your understanding of the TCP causalities or of > how the race detector is working, because it does indeed report something, > right? ;-) > > > > >> > Caleb Spare <cesp...@gmail.com> schrieb am Mi. 7. Juni 2023 um 01:31: >> >> >> >> 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. >> >> >> >> Caleb >> >> >> >> -- >> >> 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/CAGeFq%2B%3DZGE5agaLYDgsdYvykbaWwHgjtKJf9q%2B1YJhR26%3DY45Q%40mail.gmail.com >> . >> >> >> >> -- > 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/CAFwXxZTO0fsRRK%3DiShNL1xjbaXN7tDc8wN_uAy3J3FQXPwK7Pg%40mail.gmail.com > <https://groups.google.com/d/msgid/golang-nuts/CAFwXxZTO0fsRRK%3DiShNL1xjbaXN7tDc8wN_uAy3J3FQXPwK7Pg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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/CAMV2RqqicsyJv7%3DKAa4atEc%3DB%3DrdahbNw%2BzqPO7Q6CzZobCgPQ%40mail.gmail.com.
