4 ms·
> It ultimately resulted in a loop counter overflowing, which recomputed the same thing a billion of time (but always the same!). So the visible effect was a re
by wavemode 1y ago
> It ultimately resulted in a loop counter overflowing, which recomputed the same thing a billion of time (but always the same!). So the visible effect was a request would randomly take 3 min instead of 100ms.
This means that multiple goroutines were writing to the same local variable. I've never worked on a Go team where code that is structured in such a way would be considered normal or pass code review without good justification.
- bombela 1y agoIt happens all the time sadly. It's not because people intentionally write this way. A function takes a parameter (a Go slice for example) and calls another function and so one. Deep down a function copies the pointer to the slice (via closure for example). And then a goroutine is spawned with this closure. The most obvious mistakes are caught quickly. Buu sharing a memory address between two threads can happen very indirectly. And somehow in Go, everybody feels incredibly comfortable spawning millions of coroutines/threads.