On Thu, 26 Sep 2002, Charles Reitzel wrote:

> 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?

Unfortunately nope.  You are confusing a programming model with
pools.  Pools are about variable life-time.  In the case of what you are
trying to do, it is possible already.  All you need to do, is do the
initalization in the child_init phase, and save each version of the data
in a table that is accessible by the whole process.

The problem with a qorker_rec, is that it doesn't fit with the Apache
model.  Yes, it would be possible to add the pointer to the request_Rec,
but it isn't necessary.  Everything in Apache is centered around the
request, not the thread/process that is serving the data.  By adding a
worker_rec, we are actually encouraging programming practices that we
don't want, like copying a bunch of global data into a worker_pool.  We
would much rather that modules were written with thread-safety in mind, so
while it is possible to do, it isn't the right solution.

Also, we did have a thread_pool at one time that worked for threaded
MPMs.  The problem was that it just wasn't ever used.  This makes sense,
because pools are about lifetime, and in all of the MPMs (except
perchild), threads have the same lifetime as processes by definition.

I hope that makes sense.

Ryan



Reply via email to