Apologies if this is a duplicate - I had a look and didn't see anything similar to this.....
What I suggest is to allow registration of queues as user events. This would add an case in the event structure which would wait to dequeue any elements which are in the queue. I would suggest that this would act just like a dequeue element - if an element is enqueued or if one is in the buffer already it is dequeued. If there is a second dequeue event registered or a second regular dequeue element then they would compete for elements just like a normal dequeue element.
If the queue is destroyed the case would deregister - but the event structure would continue to wait for user events or static events as normal.
I would also suggest that a 'dequeue event' is only triggered one at a time and would have low priority - if a queue with 10 elements is registered, the first element is dequeued and then a FP action is generated the FP action would enter the event buffer before the second element is dequeued. I guess the behaviour I am thinking of is if you had an event case with a 1ms timeout and a dequeue element also with a 1ms timeout within this timeout case. Without the continuous looping of course.
Please let me know what you think,
Dave
Also note the text in the event registration node - my nod to this idea which I think is (also;-) well worth a kudos!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.