chrisvest
Explicit BackgroundProcess
Expose an explicit BackgroundProcess, which will be in charge of allocating background allocation threads, and other background threads, such as the time keeper proposed in #92.
The BackgroundProcess would be constructed with a ThreadFactory. Then Config would have a setting for a BackgroundProcess instance, instead of a ThreadFactory. This particular change is breaking backwards compatibility, and thus needs to be done in 3.0!
The BackgroundProcess would be reference counted from the Pool instances, so it knows when to shut down or start up. It will have to be restartable, so it remains usable even if it has previously seen its reference count go to zero.
The BackgroundProcess could use the reference count, and allocation timings, to decide how many allocation threads are needed. This would introduce two-way allocation scaling, where not only can we have fewer allocation threads than there are pools, but we can also have more threads than there are pools, if allocation is particularly expensive.
The internal refactorings done as part of #138 will make this easier to do.