Re: scalable event scheduling

On 01/28/2013 03:29 PM, Rainer Weikusat wrote:

> so easy that even using the STL implementation wouldn't be worth the
> effort

Can you clarify why we should not just use one of the STL queues
instead? If two pieces of code attempt to provide essentially the same
functionality, why not use the standard piece? I think this high-level
concern is better resolved before low-level polishing begins.

The next question is about new functionality added by the patch so it
remains valid even if we use a standard queue (or even leave the current
queue implementation in place):

> the event scheduler will store a value at the
> pointed-to location which can be passed to eventDelete to cancel a pending
> event 'safely' in logarithmic time, meaning, even if the event was
> possibly already put onto the async queue.

I cannot find the patch code which would make canceling an async queued
event work. I see that eventDelete deletes ev_tag, but I do not
understand how that will cancel the event if it is already in the async
queue. Did I misunderstood what you meant by "cancel a pending event
already put onto the async queue"?

If you did mean that events can be reliably canceled until fired, can
you point me to the right place in the patch or explain how the code
will prevent an async queued event from firing if that event is canceled
while waiting in the async queue?

Thank you,

Alex.
Received on Wed Jan 30 2013 - 15:41:37 MST