[prev in list] [next in list] [prev in thread] [next in thread] 

List:       squid-dev
Subject:    Re: threading idea
From:       Brian Degenhardt <bmd () mp3 ! com>
Date:       2001-03-19 17:59:13
Message-ID: 20010319095913.A14430 () mp3 ! com
[Download RAW message or body]

It might be useful to use the apache project as an example and attmept to
support all models.  I may have my details a little screwed up, but the
apache 2.0 architecture has what they call an MPM which an abstract model
for spawning handler thread/processes for requests.  The way it's designed
you can have multi-process MPM's or multi-threaded MPM's or a hybrid of
both.  You can also write your own MPM that takes use of your target
operating system's threading model, or perhaps use State Threads.

-bmd

On Sat, Mar 17, 2001 at 02:27:48PM +0100, Henrik Nordstrom wrote:
> 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.
> 
> The point is that there is very little data that needs to be shared
> between two different requests, and having a multi-process design is a
> hell lot easier to debug as you know there is nothing shared except what
> is explicitly shared.
> 
> Also, a multi-process design gains in stability. If there is a fatal
> error in request processing then it only hits those requests processed
> by the same process. Requests processed by other processes can keep on
> as if nothing happened. This is also true if you need to restart
> components. Simply start a new request processor and gently shut down
> the old one. The more you scale up the system the more important this
> gets.
> 
> /Henrik
> 

[prev in list] [next in list] [prev in thread] [next in thread]