Re: threading idea

On Sat, Mar 17, 2001, Robert Collins wrote:
> 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.

Threads have lower overheads, but if we went down the path of threading
squid right now, I'm prety sure we'd end up mutexing everything rather than
rewriting chunks of code to avoid mutexes. We'd then end up with something
that is totally impossible to debug.

Besidees, having a squid which _could_ be run in a parallel-squid
configuration requires some more efficiency work anyway, at the point
where we have that done we can decide whether we want to support threads,
processes, or both (with some evil global/static variable rehacking..)

Adrian

>
> 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
> >
> >
>

-- 
Adrian Chadd		"The fact you can download a 100 megabyte file
<adrian@creative.net.au>  from half way around the world should be viewed
			    as an accident and not a right."
					-- Adrian Chadd and Bill Fumerola