always spawn a worker with the task it was supposed to complete

[Link512]

For "unlimited" pools, in the original code:

p.handle.Go(p.worker)
p.tasks <- f

If in between the call to handle.Go and sending the task to the worker, another goroutine would call pool.Go, that task would "hijack" the newly created worker, causing the original send to block. This is undesirable behavior if the pool is unlimited.

The solution was to add an initialFunc to the worker, which will be executed before the worker starts waiting for new tasks. This ensures that a worker will first complete the task it was supposed to, then complete others.

[camdencheek]

Nice catch, and elegant solution!

Interestingly, I expected this to add an allocation for the closure, but TIL that closures do not allocate if all the captured variables are already on the heap.

[codecov-commenter]

Codecov Report

Merging #112 (77b74b9) into main (06d3061) will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##             main     #112   +/-   ##
=======================================
  Coverage   99.30%   99.30%           
=======================================
  Files          12       12           
  Lines         432      433    +1     
=======================================
+ Hits          429      430    +1     
  Misses          3        3           

Impacted Files	Coverage Δ
pool/pool.go	100.00% <100.00%> (ø)

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more