Greg Hupp Posted July 21, 2010 Report Share Posted July 21, 2010 I say this from a standpoint of that I have never heard of anything that ensures that they will be ordered properly. There is most likely a high likelihood that they will, but this only highlights that people write programs that assume this. If AQ or someone in R&D pipes up and says that it is ensured, then I'll fully retract that. But I will never recommend that anyone write a program that depends on having multiple Val(signl) strung together to execute the events in that order for all those reasons above. So I can second Norm's statement and say value signaling is definitely something to try and steer clear of. From code I inherited, my experience is that value signaling can cause all kinds of problems in that you don't always know the order of the firings. Using events, queue, etc are much better...and would try and guide newbies to this method rather than the value signaling. Quote Link to comment
TG Posted July 27, 2010 Report Share Posted July 27, 2010 This is new information for me as well. Can you expand on it? Under what circumstances does an event queue not execute events in the order they are received? (Munching on lunch) I also thought Events had a queue in the background that saves every event "first in last out" fashion. Tis the one main reason (speaking for myself now) why I do not consider them particularly useful or friendly (event registration or not) for anything other than simple UI stuff like management of panel buttons etc.. All that fancy stuff with events just gets me into trouble and it does not seem to be worth it most times.. As to a signaling event. Its a great (simple) way to kill an event structure from somewhere else in the VI to insure a VI with event handling shuts down on request. I've had no problems with using this technique but never considered stringing them together That would be asking for hurt down the road because there is no way to guarantee events will fire in order they are stringed up. I agree with that. Queues are far better for handling most events anyway. managing event structures is a bit of a pain and does not seem to return a lot of bang for the buck but again it's my opinion. I don't do complex event managed applications so I know they have their place. Quote Link to comment
Aristos Queue Posted March 25, 2012 Report Share Posted March 25, 2012 I say this from a standpoint of that I have never heard of anything that ensures that they will be ordered properly.There is most likely a high likelihood that they will, but this only highlights that people write programs that assume this. If AQ or someone in R&D pipes up and says that it is ensured, then I'll fully retract that. But I will never recommend that anyone write a program that depends on having multiple Val(signl) strung together to execute the events in that order for all those reasons above. I realize this is an old thread, but I was pointed toward it as a reason people should avoid Value(Signaling). So, since I am AQ :-), I will pipe up and say: Yes, the order of receiving is guaranteed to be the order of firing. The events use the same queues under the hood as the Queue functions. When you fire from parallel threads, the order isn't known any more than the order of two Enqueues in parallel would be known. But if you fire events serially, it's the same as if you had two Enqueue nodes in order: they go into the event queue in order, and, like all LV queues, they come out in the same order. There are plenty of parts of Events that I don't know, as it isn't my feature, but I know well the part of events that interacts with the queues. :-) And, for the record, in this thread you'll find my argument for circumstances when I would use Value(Signaling). I won't say it is wide open, but I believe there are legitimate, even recommended, uses for it. Quote Link to comment
drjdpowell Posted March 26, 2012 Report Share Posted March 26, 2012 Hi AQ, I thought the concern about event order was due to the fact that an event structure pulls events from multiple queues: the static-registered events, and one (or more) dynamically registered event refnums. It’s possible to fire a few events into a dynamic queue before connecting it to an event structure, so it isn’t obvious how the structure determines in what order to pull off events from multiple queues. If it uses a timestamp, then what about near-simultaneous events with the same timestamp? — James Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.