Re: Tidying up the deferred reads

On Sat, 15 Oct 2005, Adrian Chadd wrote:

> I'm not entirely sure yet, but I have a feeling the timed deferred read
> stuff I've implemented to replace the client side defer code (for
> half closed connections, but really its just a delayed read IO handler
> schduler and can be used in other places) will check after each store
> write/client read whether enough data is available in the bucket and,
> if so, schedule a server read. A delay of 1 second can be used just to make
> sure the thing is re-checked every second.

Was also thinking about scheduling a timer event when the bucket was found
empty, but the problem is that it may quite easily lead to starvation, and
also degrades fairly badly when there is many clients competing on the
same bucket.

A cleaner alternative would be to have some kind of queue mechanism on the
delay pool, serving the requests on a first-come-first-serve basis while
there is space left.. This would also give far better fairness in pool
usage than today.

The server side is all cbdata handled, so there shouldn't be any issues
with this callback from the delay pool to the server side.

Series of events:

  1. comm finds the server side fd ready
  2. delay pools indicates the pool being empty
  3. server side asks delay pools to get called when there is space
available

  4. delay pool gets refilled
  5. server side reactivated by callback in a first-come-first-serve order

Regards
Henrik
Received on Sun Oct 16 2005 - 16:45:36 MDT