Adrian Chadd wrote:
> You might not even have to care - if the object exists, you schedule a read,
> and if the data hasn't been read yet the AIO doesn't return.
Well.. you also have the issue in if the first Squid aborts the
retreival, leaving any second Squid's in the dark..
Personally I think the multiple-readers-one-retreival is often more bad
than good. It works well if all clients are of similar speed, but if the
clients are of different speeds then things begins to go crazy, and
sub-optimal behaviour is seen if the request has stalled.
So instead I propose the following:
a) If the object is currently being retreived for another client, then
handle it as a cache miss.
b) Reimplement quick_abort to instead of continue reading at full speed,
defer reading for a while and when the period has expired read what you
have. If not enought then abort the object (could be repeated a couple
of times before aborting if wanted).
d) Optionally allow a client to reassign ownership of a request
currently pending in quick_abort, but I prefer to get caching of partial
object done rather than this.
/Henrik
Received on Tue Oct 17 2000 - 08:08:33 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:12:50 MST