3 ms·
Maybe I'm dumb but I don't understand the bug. I understand why the main code blocks if no tokens are available in the found channel but why would writing to `f
by xmprt 6y ago
Maybe I'm dumb but I don't understand the bug. I understand why the main code blocks if no tokens are available in the found channel but why would writing to `found` block the code (and why only in the case when there's a lot of go processes)?
- jeffbee 6y agoIt deadlocks if len(pss) > concurrencyProcesses.
- xmprt 6y agoEven in that case, wouldn't the main loop block for a short time but then unblock after the goroutine returns (and the defer function is executed)? I thought the whole point of limitCh is to support the case where len(pss) > concurrencyProcesses but in this case you're telling me that it's breaking things?
- ben0x539 6y agoYes, that's the whole point, but it's completely broken. I've certainly made the same mistake. :D
- jeffbee 6y agoThe inner goroutine cannot return because it blocks at found<-P, because found is not buffered and there is no reader. This would work if the consumer was started in a goroutine first.
- xmprt 6y agoThanks. The part about starting the consumer in a goroutine actually made more sense as a solution than either of the given solutions. I guess I completely forgot how channels work and didn't realize that until there's a reader, the channel will block (which makes perfect sense in hindsight).
- ben0x539 6y agoWe're blocking in `limitCh <- struct{}{}` if we're trying to spawn more goroutines (because `pss` is big, representing there being a lot of processes we're inspecting, not many go processes) than there is room in `limitCh` (used as a semaphore). The newly spawned goroutines never allow the main goroutine to proceed because they never terminate, and they can't terminate because no one is reading from `found` yet, so they're blocking on `found <- P`.