Aaron Bannert wrote: >On Thu, Nov 29, 2001 at 09:20:48AM -0800, Brian Pane wrote: > >>From a performance perspective, the two limitations that I see in >>the current worker implementation are: >> * We're basically guaranteed to have to do an extra context switch on >> each connection, in order to pass the connection from the listener >> thread to a worker thread. >> * The passing of a pool from listener to worker makes it very tricky >> to optimize away all the mutexes within the pools. >> > >IIRC, the problem isn't so much the fact that pools may be passed around, >since in that respect they are already threadsafe without mutexes >(at least in the current CVS and in the recent "time-space tradeoff" >patch. I believe the actual problem as you have described it to me is >how destroying a pool requires that the parent be locked. Perhaps you >can better characterize the problem. >
Right--the fact that the transaction pools are children of a pool owned by the listener thread means that we have to do locking when we destroy a transaction pool (to avoid race conditions when unregistering it from its parent). --Brian
