Event When User Event Becomes Invalid

[Hooovahh]

So when it comes to using a queue, there is a somewhat common design pattern used by NI examples, which makes a producer consumer loop, where the consumer uses a dequeue function with a timeout of -1.  This means the function will wait forever until an event comes in.  But a neat feature of this function is it also returns when the queue reference becomes invalid, which can happen if the queue reference is closed, or if the VI that created that reference stops running.

This idea is to have similar functionality when it comes to user events.  I have a common design pattern with a publisher subscriber design where a user event is created and multiple loops register for it.  If for some reason the main VI stops, that reference becomes invalid but my other asynchronous loops will continue running.  In the past I've added a timeout case, where I check to see if the user event is still valid once every 5 seconds or so, and if it isn't then I go through my shutdown process.

What I am thinking is that there could be another event to register for, which gets generated when that user event which is registered for, becomes invalid so that polling for the validity of the user event isn't necessary.

before:

after:

[Intaris]

Just for clarification: I took the comparison with Queues too literally earlier and essumed the idea was somehow to destroy the registration refnum queue when the user event becomes invalid.  This I would object to because I rely on this not happening in some of my code (and would violate the "Listener controls the lifetime of the communications pathway" idiom).

With a queue, if you send X messages and then destroy the queue, a listener who later starts listening to the Queue will receive no messages but an error because the Queue has been destroyed (communication has been disrupted).  With Events, this is different. If we register for an event and fire off X events and then destroy the User Event, we still get all X events even if we only actually wire up the registration refnum hours later to an event structure.  This should remain.  We should still get ALL of the Events sent over a User Event which has been registered for and then at the end (with correct ordering), this "User Event destroyed" event.  The independent lifetime of a User Event and Registration Refnum is an important difference for me and is a cool feature of User Events I rely on.  I'm assuming this aspect is actually fundementally important to the idea as amended.