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.
BTW, +1 for the patch.
Ryan
______________________________________________________________
Ryan Bloom [EMAIL PROTECTED]
Covalent Technologies [EMAIL PROTECTED]
--------------------------------------------------------------