Event/Queue merger

[GoGators]

An interesting API was recently discussed with me. Apparently you can use the ActiveX/.NET register event node to register standard LabVIEW UI events (through UI refnum). Why might this be interesting you might ask? Well for a long time I have thought that the deviation between queues/event structure was unneeded. This suspicion was reinforced when the topic came up in the CLA summit. The queue and the event structure have a lot of overlap. The question is should the two implementations be merged?

I've talked with some who think that the event structure is more data flow oriented, but I am not entirely convinced.

Just so you can test it, here is some example code I posted to benchmark the callback API (ActiveX/.NET) and the dynamic event mechanism

CBvsES.zip

[ShaunR]

An interesting API was recently discussed with me. Apparently you can use the ActiveX/.NET register event node to register standard LabVIEW UI events (through UI refnum). Why might this be interesting you might ask? Well for a long time I have thought that the deviation between queues/event structure was unneeded. This suspicion was reinforced when the topic came up in the CLA summit. The queue and the event structure have a lot of overlap. The question is should the two implementations be merged?

I've talked with some who think that the event structure is more data flow oriented, but I am not entirely convinced.

Just so you can test it, here is some example code I posted to benchmark the callback API (ActiveX/.NET) and the dynamic event mechanism

It depends on what you mean by "merged". I use named queues rather than a named types which means that (amongst other things) I can send a string across the network and dynamically create a queue with that name at the other end.. I can't think of a way (off the top of my head) that I could easily do that with events. But generally. I think queues are easier to use since you just grab a reference by the name from any module without having to run wires or store the ref in a globally accessible storage. But apart from that. Yup. they are pretty similar (maybe because events use a queue?).

Interesting to note that there is about 20% a difference in performance though (although I haven't looked closely at the test method)..

Edited March 22, 2011 by ShaunR

[Götz Becker]

I really like the idea of a more callback oriented UI handling in LV, but currently it's unusable. LV just hangs/crashes on filter events CAR: #42806

The other caveats are that you have to check if the FP of the control to un-/register is open. Unregistering the callback to a control with its windows closed leads usually to a VC++ runtime error "R6025 - pure virtual function call" at application termination.

During development and "abnormal" program termination aka Stop-Button often the callback VIs are blocked for editing because of running/"reserved fo run" reentrant instances of them.

[Black Pearl]

I don't think both are really similar. Just to highlight some major differences:

* Q's can be used as data structures: FIFO, stack (FILO) -> recursion, SEQ.

* Events can be used as a one-to-many or many-to-many communication.

Felix

[GoGators]

* Q's can be used as data structures: FIFO, stack (FILO) -> recursion, SEQ.

I think those differences come from the fact we have access to both the read/write API of the queue. We only have access to the read portion of the event structure. Using the ActiveX node means we retake the write portion.

* Events can be used as a one-to-many or many-to-many communication.

Once again that is because when the event is triggered the writing potion of the event writes to the queues of all the subscribers event queues.

[Daklu]

The question is should the two implementations be merged?

Merged? Like Shaun I assumed the event infrastructure was already based on queues. Since it's pretty straight forward to replicate user event functionality using queues I view events as a higher level abstraction of specialized queues. I'm not sure how you can merge them without giving up some low level control over queues or high level simplicity of the event structure. The prospect of having to create and register a callback vi to handle every fp event doesn't excite me. I like how the event structure simplifies that for me. Personally I think the event implementation is very good with respect to fp events.

If we start talking about user events, well... they are not as useful as I had hoped when I originally dug into them several years ago. I know I've mentioned it in other threads and I know I hold a minority opinion, but I don't see any good generalized implementations that take advantage of user events' one-to-many capability while maintaining robust coding practices. On top of that, when a given component receives both queue-based and event-based messages they usually have to be combined somehow so a single loop executes both messages. That's not particularly hard to do, but it does require more code and can become a pain in the neck when it has to be done for every component. (Incidentally, the typical technique of nesting an event structure inside a queue-based message handling case structure isn't, IMO, a particularly robust solution. But I digress...)

I agree there is significant functional overlap between queues and user events, but I don't think the APIs should be merged.