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.
Brian this sounds similiar to the 'Leader/Follower' Pattern in the ACE framework (http://jerry.cs.uiuc.edu/~plop/plop2k/proceedings/ORyan/ORyan.pdf) > > So...please forgive me if this has already been considered and dismissed > a long time ago, but...why can't the listener and worker be the same > thread? > > I'm thinking of a design like this: > > * There's no dedicated listener thread. > > * Each worker thread does this: > while (!time to shut down) { > wait for another worker to wake me up; > if (in shutdown) { > exit this thread; > } > accept on listen mutex or pipe of death; > if (pipe of death triggered) { > set "in shutdown" flag; > wake up all the other workers; > exit this thread; > } > else { > pick another worker and wake it up; > handle the connection that I just accepted; > } > } > > --Brian >
