On 4/5/06, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote: > Final observation, your model seemed a little shortsighted, in that it permits > only a single thread pool. This is great for an app, lousy for another > library > which wishes to build upon the model. And a group of threads might be shut > down > independently of a second pool. > > Can you refine the proposal with an apr_threadpool_t * object which prevents > us from adding yet another evil static singleton? Or as an alternative, bind > the threadpool as an attribute of the pool itself, identifying the thread pool > by apr_pool_t *?
I'd prefer a separate threadpool object, but yes, I agree that the API needs to allow for multiple pools in an application. -garrett
