Thanks for telling me what I need to know: "you can't get there from here."
I don't want to start a philosophical debate, but it is a common idiom (yea, verily a "pattern") in multi-threaded programming to avoid contention by duplicating singletons in each thread. This can be done either by using platform-specific thread-local storage or, portably, by passing in the needed singleton (or a place to put it) into the worker thread. A mutex-free, per-thread pool would serve this purpose perfectly. Change the word "thread" to "worker" in the above, and you have made it portable across MPM models. A per-thread pool would assist a great deal in bringing many Apache 1.x modules over to 2.x. In essence, you move the globals into the per-thread pool, and the remaining application semantics are unchanged. You can't "just add synchronization" to most applications/modules. Usually, you need to redesign much of it to make it work without killing performance. Convinced? take it easy, Charlie On Wed, 26 Sep 2002, Ryan Bloom wrote: >You shouldn't be trying to access a per-thread pool. It isn't necessary. >The pool in the request-rec, is by definition, only available within that >request, which is limited to a single thread. The only reason to access a >per-thread pool, is if you want to allocate memory that has the same >lifetime as the thread itself. There is currently no way to do that, but >there also hasn't been a convincing reason to do it. Ryan
