@craig S. wrote:
...
if every Event structure had a separate queue per event, it would be very hard to maintain the rule that events are handled by the Event structure in the order they occur. It's not hard to see that this is an unworkable idea.
...
I agree that it might not be
as easy to maintain the rule that events are handled by the Event Structure in the order that they occur (is that a strict requirement that cannot be broken in special configurations/instances?) and I don't see how it is an
unworkable idea.
If each an event structure (dynamic registration) had a seperate queue per event, and a single, additional queue used only for event ordering, then it would be possible to manage each seperate event queue. If a queue was bounded with overwriting allowed (a lossy queue) then you could define one of two configurable behaviors:
1) Events are processed in the order that they occur. This is achieved by deleting the oldest reference to that event in the event ordering queue and enqueing the new event reference to the back of the event ordering queue.
2) Events are allowed to cut in line. Do not enqueue a new reference in the event ordering queue -- simply overwrite the events in the event queue. This means that the oldest event is overwritten and each event bumps up in line to the location where the previous event was located.
I think that just providing these two options would be enough for 99% of use cases. And, I think that the implementation is far from unworkable.
LabVIEW user groep 