threadpool.stopAWorker does not cause join() on stopped workers

[robertc]

while this isn't strictly a bug, it is a leaked object that will wait for gc to actually get cleaned up. This can cause some confusion in tests that want to examine the number of threads, or cause an overly large number of workers - e.g. doing reactor.suggestThreadPoolSize(10) # start stuff in threads reactor.suggestThreadPoolSize(1) # assume its all good # start something big

can trivially result in 11 things actively running at once - because the worker count is decremented when a Stop is queued, not when a Stop happens. rearranging things so that the active worker count is synchronised, and correct, would permit join() of stopped workers safely (rather than waiting for gc) and also prevent foot-shooting when changing the thread pool size for whatever reason.

There is a FIXME in the stop() method that would also get addressed by doing this.