Re: threading (Re: ideas)

This is in line with the path we (well, me and Adrian) have agreed on,
except that we have even less of threading/locking issues related to the
actual request forwarding. All of the request is handled in one thread,
no request dispatcher outside the OS dispatching requested connections
to the "threads", and communication to the storage is asyncronous and
isolated.

What we will essentially be doing is to split the storage I/O from the
networking I/O allowing multiple networking I/O "threads" to work
against one persistent cache storage.

Due to various reasons we are currently aiming for a multi-process
rather than a multi-threaded design at this time. My intention is
however to make the design generic enought that it could easily be
converted to a threaded model (or the other way around)

Why we are going for a multi-process design rather than a multi-threaded
design:
* Portability. What we are playing with here requires proper kernel
threads support, and unfortunately a number of the target platforms of
Squid does not support kernel threads.
* System reliability. A fault in one component does not have to bring
the whole software system down, and the code can gracefully recover in
an speedy manner.

--
Henrik Nordstrom
Squid hacker
Jon Kay wrote:
> In the case of Squid, I would suggest processing requests very nearly
> as much as is already done in a single thread of control, and adding
> thread-conscious code at three points: request dispatch from
> comm_select(), storeGet()/storeLockEntry(), and where diskio threads
> off now.  Request dispatch should probably be the only place where
> threads are created, and only if 'necessary'.  This is the minimum
> needed to take advantage of SMP and processing requests while waiting
> for disk.