tree 988dc85d6f4911239d54a71f7d7376675fc8d39d
parent 9668e36a63e12fdc19489759df942a2dae755a67
author Mircea Trofin <mtrofin@google.com> 1664481259 -0700
committer GitHub <noreply@github.com> 1664481259 -0700
gpgsig -----BEGIN PGP SIGNATURE-----
 
 wsBcBAABCAAQBQJjNffrCRBK7hj4Ov3rIwAAx1QIAChCYDvp62MMXYL237LO9zbF
 4iYsMRtJX+X08jLyO3D1+uhXuAa/Akj9ECoHccF4b1glV5rkS8oPtVsnDORrWCO/
 bG36+zpGrr66EZsGHKF9PhqnwGq8W7YM1nz3M/fQs6RqBMrrzBIZ/Ce+WDGayyWY
 cOQFBQ3uwg2xl1yvIPIywYzH2dLoivwqUtZDSCvYNozrIHm0H5OUcsbsKG6mdRLN
 RNRO6ipZ2dCHbOp22Okj0ei/ANdxfjAyE4c4I4RhI2HSsvvR0fYFlmv2wD9enacg
 /0ASFxl3wOGVdARmJ0PrgWMWM8nhy18CUrZYuY0wVKhuZujlXNv/QdGNSar/DbE=
 =n7eV
 -----END PGP SIGNATURE-----
 

Have the worker pool context produce a pool object (#154)

The motivation is:
- allowing worker managers specify the level of concurrency for a
  worker. This is set to '10' right now by the data collector, but it's
  really specific to the worker set up. For the local case, where we max
  out the hardware threads with workers, 10 is overly-generous. For a
  distributed case, a number approaching the hardware threads would be
  more appropriate
- allowing distributed worker managers update the set of available
  workers over time. Workers could get preempted, or new ones become
  available. Having a way to periodically check and update what's
  available - albeit there are never guarantees a worker, once
  discovered, stays alive - helps avoid artificial starvation.

The rest is renames that fall out of this refactoring.