Re: delay pools and fd_set 's

On Thu, 2003-02-27 at 22:49, Adrian Chadd wrote:
> On Thu, Feb 27, 2003, Robert Collins wrote:
>
> > > What do people think?
> >
> > I'm working on a more generic solution at the moment, consolidating
> > deferred reads and delay pools etc......
> >
> > Rough notes in bugzilla, or pop onto IRC and we can discuss...
>
> Can I have a look at what you've done?

Sure. I'm pushing the arch mirror now. It's in the epoll branch
(robertc@squid-cache.org--squid/squid--epoll--3.0).

Basic current outline is:
1) Remove accept defer limiting (done, via AcceptLimiter singleton).
1a) Make deferral calls into amount limiting calls throughout.
2) Ensure that all maybe-limiting deferred read hangler reads are *not
scheduled*. (to do - audit begun).
3) remove *defer* calls.

enlarging on 2)... we know for all FD's when we might want to defer the
read - we can check this before scheduling the read, and instead place
the reader in a queue, to be kicked off when the reason for the deferral
changes (i.e. the delay bucket frees up space, or the client reads data
reducing the read ahead gap).

There is some serious work involved in 2), but should produce more
scalable results:
*) No checking for deferral on each io loop.
*) Edge triggered approach, rather than level triggered.

I think a variant on the AcceptLimiter class will make implementing 2)
quite easy, once the read and edge detection logic is appropriately
factored in each IO area.

Rob

-- 
GPG key available at: <http://users.bigpond.net.au/robertc/keys.txt>.