Deferred reads

The next step in my nefarious plan with the comm code is to make
squid work well with event driven systems such as FreeBSD's kqueue
system. In this light, I'd like to kill deferred reads. The
problem with the curent deferred reads setup is that you can
only really throw away the read handler call after you have the
read event, and if you have lots of deferred reads your event
queue spends most of its time returning fds that will be
thrown away anyway.

There are five functions passed to commSetDefer:

httpAcceptDefer - defers accepting HTTP connections if we are out of fd's .
clientReadDefer - haven't figured this ne out yet
sslDeferServerRead - used only if DELAY_POOLS is enabled
pumpReadDefer - used so PUMP_MAXBUFFER isn't overflowed
fwdCheckDeferRead - don't read too far ahead from server if clients are lagged

Now, from what I can see these can be replaced with either periodic events
or properly scheduled reads.

Since this is part of the commloops development, I'm going to
start removing these and replacing them with suitable interfaces.
Can anyone think of a reason to keep deferred reads?

I'd also like to add a 'comm_read' routine similar to comm_write
which code can call when they want a read scheduled, rather than
calling commSetSelect() and read(). I had it partially implement
for the HTTP client and server code a while back when I was playing
with a POSIX AIO squid and I think it could be useful here
(so you can throw a read request out to another thread which could run on
another CPU while the first CPU only handled the main squid loop..)

Comments ?

Adrian

-- 
Adrian Chadd			Build a man a fire, and he's warm for the
<adrian@creative.net.au>	rest of the evening. Set a man on fire and
				he's warm for the rest of his life.