Ryan Bloom <[EMAIL PROTECTED]> writes:
> On Tuesday 28 August 2001 04:03, Jeff Trawick wrote:
> > Aaron Bannert <[EMAIL PROTECTED]> writes:
> > > This patch implements a resource pool of context pools -- a queue of
> > > available pools that the listener thread can pull from when accepting
> > > a request. The worker thread that picks up that request then uses
> > > that pool for the lifetime of that transaction, clear()ing the pool
> > > and releasing it back to what I'm calling the "pool_queue" (har har).
> > > This replaces the prior implementation that would create and destroy
> > > a transaction pool for each and every request.
> >
> > (surely I'm missing something here... need to brew some coffee...)
> >
> > It seems that you allocate a ptrans for every thread but rather than
> > store it in some thread-specific data you treat it like a shared
> > resource, storing it in a queue, which introduces serialization and
> > other overhead.
> >
> > If every thread has a ptrans, which it should, this overhead is
> > unnecessary; the ptrans shouldn't be held in a shared data structure.
>
> How do you determine which ptrans to use unless it is a shared
> resource? The ptrans needs to be accessible by the listener to call
> accept with. If it is local to the worker thread, then you can't use it
> in the listener.
Yes, that is true... I didn't even remember the code in my own MPM
which has an accept thread and does essentially the same thing.
--
Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
