Seebs 66e079f1e9 task pool: avoid race condition on shutdown/close ... When we close a task pool, we use a condition variable to wait for workers to exit, if any workers are still running. The workers, in turn, use the condition variable to notify that they've exited. Unfortunately, the workers aren't using the lock (the rationale was that it's all atomic ops so they don't need to), which means that it's possible to have the following sequence: Close(): obtain current live count worker: decrement live count worker: send broadcast to condition variable Close(): wait on condition variable To resolve this, we make the worker update also request the lock. We add a simple reproducer for this. Note that simple doesn't mean it fires completely reliably; on my laptop, the test causes a test timeout about 60% of the time without the fix. If you add a short delay between sampling the live count and waiting on the condition variable, the deadlocks move from "60% chance of hitting it in a million trials" to "nearly always".		2023-02-17 11:32:07 -06:00
..
doc.go	Updated code to latest version for open-sourcing.	2022-09-02 13:23:39 -07:00
pool.go	task pool: avoid race condition on shutdown/close	2023-02-17 11:32:07 -06:00
pool_test.go	task pool: avoid race condition on shutdown/close	2023-02-17 11:32:07 -06:00