MJE Subpanel Config Dialog LV2013.zip

[drjdpowell]

Ethan Stern wrote:

                       

I tried the approach of registering events not on the block diagram of an Actor Core.vi--it doesn't work. I'll just be lazy and ask: what is the condition that causes this "remote" registration to sometimes work and other times not?

                   

Was the registration in a different Actor?  Or in a VI that "launches" the Actor.  Because then the registration is "owned" by that VI hierarchy and will be destryed if that hierarchy goes idle.

Also, was the Front Panel for which events are being registered loaded in memory before registration.   This one is always biting me.

[kegghead]

Regarding the hierarchy going idle, this can definitely be an issue but I'll point out would not be isolated to events or event registration, or to the actor framework specifically. This is a more broad set of race conditions that arises with managing lifetime of asynchronous tasks. Definitely could be the cause though.

As for splitting the registration refnum wire. I dislike saying "never do this" because one can always come up with an escoteric use case to show where the resulting behavior may actually be wanted. If we take a step back and think about what events and the corresponding registration refnums encapsulate the behavior makes sense. The event implements the mechanism of tracking who its subscribers are and sending event data to those subscribers. The registration implements buffering data received from the event until it can be handled. The two tasks are distinct and are important to understand for lifetime of data sent through the event.

Think about this sequence of events:

1. Create an event.
2. Register for the event.
3. Broadcast a single event datum.
4. Destroy the event.
5. Send the registration into an event structure. This will wait for event data.

Does this VI return or hang? Is the result reliable? Why does this happen?

Stop reading here if you'd like to work through those questions, the next paragraph doesn't answer them but may provide clues.

Getting back to splitting the registration refnum. If you think about the registration refnum as encapsulating a queue or mailbox, it makes sense why you should "never" split this wire. If I have two consumer loops acting on a single queue, I would not expect both loops to be able to act on an enqueued element. One will always get it first. Predicting which will get the queued element though becomes next to impossible. This isn't exactly how an event registration works, but the the analogy works. Two structures acting on the same registration refnum result in two consumers of a single buffer. When one of the structures fails to receive an event the other did I wouldn't argue that's a missing event...it's a result of the race condition that's been baked into that code. Entirely expected.

[drjdpowell]

kegghead wrote:

                       

As for splitting the registration refnum wire. I dislike saying "never do this" because one can always come up with an escoteric use case to show where the resulting behavior may actually be wanted.

The problem with a split registration is that one or more (but not necessarily all) event structures will act on the event.   With a split Queue one and only one dequeue will get the element from the Queue.   The later behavior is what is needed in a "work pool" design, but I'm not sure the former is ever useful.

[kegghead]

Yeah, as I implied, the analogy breaks down. There's some weird stuff that goes on with the registration implementation. I wish I knew what it was behind the scenes.

[Station3]

Having multiple event structures act on the same programmatic event ("user event", badly named) has been useful for me.  I like to use event-based messaging more often than queue-based.  I'll have one process send a message to all parallel processes like an overall system mode change or 'quit' command.  This architecture works if it's the event refnum I'm branching to all parallel processes, and I give each event structure its own Register For Events node.  This architecture malfunctions if I instead use one Register For Events node and branch the event registration refnum.

[kegghead]

Yes, the one-to-many nature of events (and the registration thereof) is very useful. I too prefer them over queues in pretty much anything other than direct producer-consumer links.

[drjdpowell]

I hardly use the one-to-many features of events (I have an alternate method of one-to-many).  What I like is the many-to-one nature of the event structure, where I can listen for messages on a User Event, while listening to other type-specific user events, while responding to FP events, while receiving DAQmx or IMAQdx events.  When you are waiting on a Queue you can't wait on anything else.

[EthanStern]

I'm revisiting this thread after a long absence because events came up during our last Mass Compilers meeting. I did end up testing the scenario that I posed earlier and it worked just fine. I can't remember--back when I had this problem with dynamic registration--if I was registering multiple overrides of Actor Core for the same event. The "problem" might have been entirely caused by my misuse of events in general.

In any case, this discussion was really interesting and might become the topic of a future user group meeting. Let me know if you'd like to contribute!