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.
