Threaded ICP loop

--MimeMultipartBoundary
Content-Type: text/plain; charset=us-ascii

Hiya,

        In expanding the thread model, taking a look at the ICP code now
that UDP_HIT_OBJ's are gone, it looks like a fairly easy task to convert
the ICP code into a separate subloop which can either be called on demand
from main squid, or be split into a thread and have the thread call the
subloop over and over again (but can block since it's a thread). With
ICP for our parent caches hitting over 400 transactions/sec, this seems
like an ideal way to take advantange of multiple CPUs (which we and others
may have).

        My honest belief is that a fully threaded squid is ultimately the
way to go, but resource contention issues need to be ironed out. ICP is
however one thing that CAN be split out right now, and should be. So when
the next version of 1.2beta (14?) pops out, I want to do this.

        If there is any advice/objections then let me know now.

        Basically I'll be splitting comm_{poll|select}_incoming into two
separate functions which can either both be called in comm_{poll|select},
or the ICP sub-split be threaded.

        This will require mutex's on the store hash table, but I'm aiming
for one mutex per hash line to greatly minimise contention.

        Stew.

--MimeMultipartBoundary--
Received on Tue Jul 29 2003 - 13:15:45 MDT