Aaron Bannert wrote:
[...]
>1) "short and sweet"
>
> - single listener
> - creates a new transaction pool
> - uses that pool for the next accept()
> - push()es the newly accepted socket and pool on the fd_queue
>
> - multiple workers
> - waiting in pop() on the fd_queue
> - performs process_socket() with the socket and pool received from pop()
> - destroys the pool
>
> Notes: this is almost identical to what was in CVS before the patch
> discussed below. The only change I would make would be to
> remove one of the two condition variables.
>
>2) "time-space tradeoff"
>
> - single listener
> - pop()s the next available worker-thread
> - uses the pool from this worker-thread to make the call to accept()
> - signals a condition in that worker-thread after the accept()
>
> - multiple workers
> - creates a transaction pool
> - push()es thread info (pool, socket-pointer, etc)
> - waits on signal from listener
> - (check that listener woke us up)
> - perform process_socket() with the socket set from the listener
> - clear the pool
>
I suppose there are a total of four candidate designs, right? It looks
like you're varying two independent dimensions:
* condition variable strategy: one CV, or one per thread
* pool strategy: worker-managed, or listener-managed.
so there are four possible permutations. (The other two
permutations would look like hybrids of "short and sweet" and
"time-space tradeoff." I don't know whether they're interesting
algorithms or not, but it's worth noting that these hybrids are
a possibility if you find in testing that neither of the first
two designs stands out as the clear winner.)
In the "pool strategy" dimension, I think a worker-managed pool design (as
used in "time-space tradeoff") is a better choice than a
listener-managed one.
With worker-managed, you can clear and re-use the pool, which is cheaper
than
destroying and recreating it. And it's very easy to eliminate locking for
subpool creation by adding a thread-private free list (you could dig up my
old patch for this, or Sander's patch which is a more general-purpose
solution).
In the "CV strategy" dimension, I'll wait for benchmark results before I try
to guess which approach is fastest. :-)
--Brian
