Event Inspector Window - Unhandled Events: "how bad" are they?

[fabio.int]

Hello,

can I read the sequence # in the event structure? I mean, I'd like to understand the sw flow during the run time and I need the sequence#, at the moment I'm doing it by myself. Please see the attached VI.

Thank you,

Fabio

[Mark_Yedinak]

First, you should have started a new thread for your question. It has nothing to do with the original topic. Secondly, use a shift register for your sequence number. Then you can access it in any case of the event structure. It will need to be wired through all event cases.

[joerg.hampel]

---

@Intaris wrote:

I have just tested it and it is indeed exactly as mentioned, an Event structure deletes all registered events which it is not told to handle.

---

I know this is an old thread, but I just ran into it when researching a specific aspect of the topic, and for the sake of posterity, I wanna clarify (or maybe just say in my own words?).

Regarding programmatically registered events - both user events and UI events:

• An event structure handles all events contained in the event registration reference that is wired to the Dynamic Event Terminal (usually that means all user event references that are wired to the event registration node).
• If there is no event case in the event structure for any of the registered events (the event inspector window calls those "unhandled"), those events will be silently discarded.
• The event structure can only discard events when it's "entered", i.e. when it is waiting for events or for the timeout. This means that as long as a case in the event structure is executing, it cannot discard any unhandled events.

The last point led to a nasty memory leak in one of our customers' application, where the event structure was stalled in one case, which led to unhandled events not being discarded, which led to a crash eventually.

Also, since the last comment here, a new source for learning is available: Olivier's great presentation about "10 things to know (or more) about events in LabVIEW"

[Intaris]

The status of being handled or unhandled by the event structure here is a bit of a red herring.

This would result in RAM consumption independent of whether the events are handled or not, no?

[joerg.hampel]

@Intaris wrote:

The status of being handled or unhandled by the event structure here is a bit of a red herring.

This would result in RAM consumption independent of whether the events are handled or not, no?

---

I agree, yes. Here's my understanding:

• For each event that we register for, the event registration creates an event queue behind the scenes.
• From the point of time of the registration, events are enqueued and thus use up RAM. 
• Only an event structure (ES) can dequeue events (and thus free up memory).
  • if a case was created inside the ES for an event (NI calls this "handled"), it is processed and its memory freed up only whenever this case executes
  • if no case is present in the ES for an event (this is "unhandled"), it gets discarded only while the event structure waits for the timeout or other events to happen - i.e. those events do not get discarded while any other event case is being executed (or, obviously, if the ES is not executed at all)

Reading it back, it makes sense. I don't think I've ever thought about this (and picked my words) so diligently 🙂

---

[Intaris]

---

@joerg.hampel wrote:

Reading it back, it makes sense. I don't think I've ever thought about this (and picked my words) so diligently 🙂

---

---

Understanding precisely how Event Structures and Events in general work has been a real revelation to me. Jack Dunaway's post from years ago opened my eyes to how it actually functions "behind the scenes".

Events which have been registered (either statically within an ES or dynamically via "Register for events" node) are "deallocated" when they are handled or the "Event Registration Refnum" of the associated event registration is destroyed.

An event which is "next" in the execution queue of an Event structure (ES maintains order of execution of events across multiple different events) will be deallocated whether it is handled or not..

This changed in LV 2013 IIRC. Up until then, the memory leak was present even if the ES didn't hang. The events would be queued up and never handled, and thus never deallocated.