Re: Event order

On Fri, 2007-07-27 at 09:08 +1000, Robert Collins wrote:
> On Thu, 2007-07-26 at 09:31 -0600, Alex Rousskov wrote:
> > Folks,
> >
> > There are at least two known difficult-to-reproduce bugs that may be
> > explained by asynchronous calls being called out of order. I do not know
> > whether out-of-order execution is indeed their cause, but they prompted
> > me to investigate event scheduling further.
> >
> > Currently, asynchronous calls are implemented using addEvent with
> > 'when' parameter set to zero. This means that the event time is set to
> > current_dtime in EventScheduler::schedule. However, current_dtime may
> > _decrease_ when the system clock is adjusted. If such a decrease happens
> > between the two asynchronous call submissions, the later call will be
> > fired first.
> >
> > I see two ways of fixing this:
> >
> > 1) Stop using addEvent for asynchronous calls. Add a special queue for
> > them and drain the queue every select loop. Pros: straightforward design
> > that is probably a little faster than addEvent because we will always
> > append the new call instead of searching for the right place in the
> > queue. This design will help treating asynchronous calls specially in
> > the future (e.g., debugging and exception trapping). Cons: lots of work
> > and current code changes.

Oh, I should note - its dead easy to add a new dispatcher that just
implements a FIFO of queued calls per event loop, using the current
event infrastructure. It may be overengineered, but it makes such
additions trivial.

-Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.