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
