LabVIEW
Darren's Occasional Nugget 08/07/2023
As Steen pointed out, there is a potential race condition in the example. You could avoid that by using data flow dependency. The Register User Events node does have error in an error out terminals for some reason! 😀
The delay after the Register User Event node is not really needed, it just is there to make it more obvious that the event queue still exists after the events are destroyed.
@Darren wrote:
It turns out that with events specifically, if you destroy the event reference, an event structure frame for that event will still fire if the event is already in the event queue. This makes events unique among other APIs (queue, notifier, etc.). For example, if you have a queue with elements in it, and you destroy the queue reference, you cannot then dequeue elements that were still in that queue.
I think this remark is a little short in explanation. If you have an unnamed queue, then it is of course destroyed when calling the Release Queue node so there simply is no queue anymore left to deque anything from, no matter how many queue elements were in there the moment you called Release on it. But if you use named Queues and Obtain two Queue refnums to that queue, you can perfectly well release the refnum that was used to enque elements and still deque from the other refnum all the elements in the queue.
I'm pretty sure that the Register Events node actually Obtains a refnum to the event for the duration of its call to make sure the event object won't suddenly go away while attaching the event queue to it. Those objects like Queue and Notifier all are internally refcounted objects that allow to obtain a new refnum on it and releasing that refnum won't destroy the object until the last refnum was released.
I have wanted User Filter Events a few times. But every time I feel like I need it, I usually get around it by just reading the event, evaluating if I want to actually take the action, then do nothing with it. This can usually handle these events quickly enough to make it feel like a filter. Darren's demo makes sense to me only because I think of User Events as a Publisher Subscriber model, and each unique registration to user events needs to be autonomous. So destroying the User Event shouldn't stop the queue that was built up. Still I would have tested this behavior before trusting it. For shutdown that is great advice to just fire and move on.
Here's an updated diagram that doesn't include the race condition, since that was tripping up some people. I also simplified some other stuff too. I'll ask the moderator to update the image in the original post. Thanks for the feedback, everybody.
