Re: Download hanging

lör 2006-08-05 klockan 15:49 +0800 skrev Adrian Chadd:

> When I went through this exercise a while ago my solution was to make sure
> I 'kicked' (ie, started another comm read event) the server side if
> all the clients had read all the data they could (and thus -someone- had to
> kickstart an IO event.)

We kind of do today as well, with the defer function being main
responsible for when to back off, and I/O kicked alive again by other
functions when they think I/O need to happen.

The main reason to why the defer function exists is actually delay pools
where there is no practical signal going back to the filedescriptor when
the pools have been filled up. The store input backoff can very easily
be moved to storeAppend() today eleminating that aspect of the defer
function.

Ideally delay pools would kick the I/O going again when the pool have
been filled up, and we could then get rid of the periodic repoll of
deferred connections relying almost exclusively on
storeDeferRead/storeResumeRead signaling to indicate when I/O should
take place. (not sure delay pools should be using these.. probably the
low level commDefer/ResumeFD like today, but maybe..)

Regards
Henrik