On Mon, Oct 17, 2005, Henrik Nordstrom wrote: > 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.
Hm, not if you checked every time the client side had written some data to the client - if at this point the bucket has filled up a little then you immediately delete the timed event and reschedule IO. > 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 I'll have more of a think about it after I've completed removing the current commDefer stuff and its been tested. What do i have to do to get more people to test - re-implement kqueue/epoll? :P Adrian
