Re: threading idea

I'm new to looking at this in the context of squid - What are the
tradeoffs (or the archive threads pre mid 2000) that make multi process
"better" than multi thread? It seems to me that handling memory across
threads is easier and more portable than efficient shared memory across
process's.

Rob

----- Original Message -----
From: "Henrik Nordstrom" <hno@hem.passagen.se>
To: "Robert Collins" <robert.collins@itdomain.com.au>
Cc: <squid-dev@squid-cache.org>
Sent: Saturday, March 17, 2001 9:17 PM
Subject: Re: threading idea

> I am not considering making Squid multi-threaded. I am considering
> making it multi-process designed.
>
> No, the "thundering herd" problem does not really apply to Squid. It
> applies where you have a large bunch of processes all listening to the
> same port (i.e. ala Apache), but in this case we will only have a
small
> number of processes, equal to the amount of CPU's available. It does
not
> matter if all of them wake up when there is one or more new connection
> request.
>
> What gets a bit tricky is how to evenly distribute the request load
> amongst the CPUs and perhaps how to avoid kernel-level congestion on
the
> listen port (if there is such a thing on non-blocking listen ports),
but
> I am confident a nice design for distributing the connection requests
> can be found.
>
> /Henrik
>
> Robert Collins wrote:
> >
> > I don't think this has been proposed before but if it has just point
me
> > at the archives...
> >
> > Alter squid to have a worker thread for each cpu, and a control
thread
> > which handles the select loop, logging, and adding items to the work
> > queue.
> >
> > The core idea being that when 2 or more requests would be acted upon
> > from the current core loop, they can be processed in parallel, with
the
> > same non-blocking request processing logic as today.
> >
> > Issues:
> > Some of squid is non-reentrant, and much non thread safe (ie mutex
would
> > be needed on global variables, or data structures that could be
accessed
> > in parallel.
> >
> > benefits:
> > Should be able to more effectively utilise dual processor machines.
> >
> > Thoughts?
> >
> > Rob
>
>
Received on Sat Mar 17 2001 - 03:39:40 MST