On Tuesday 28 August 2001 07:04, Jeff Trawick wrote:
> 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.
I'm likely to apply this when I get to the office in about an hour.
Ryan
______________________________________________________________
Ryan Bloom [EMAIL PROTECTED]
Covalent Technologies [EMAIL PROTECTED]
--------------------------------------------------------------
