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
signature.asc
Description: Detta är en digitalt signerad meddelandedel
