Are Events Lossless?

[drjdpowell]

Not for User Events i.e. the ones which you fire by calling Generate Event with some data

User Events aren’t front panel events, and should never lock any front panels.   

[AlexA]

Ok, with red face I must admit having discovered the real source of the problem.

It was an unforseen race condition (of course) which was actually happening due to the computer moving faster than the hardware it was controlling. The hardware control process would enable the controller and then immediately check the FPGA status (a "control enabled?" indicator which depends on more than just the user's input), as the FPGA control loop only runs at 20kHz, I believe that the "control enabled?" indicator wasn't being updated before the check.

 

Sorry for the run around!

[bbean]

For me the event structure is in a state machine, and after getting an event will go and o what it needs to.  During this time the UI is no longer locked and will respond.  So one solution is to make the code in the event structure very minimal so it locks the UI but only for a fraction of a millisecond. 

 

Obviously this depends on the circumstances, but what mechanism do you use to execute the "do" portion of code that could hold up the event structure?  Do you just pipe information into a parallel queued state machine or actor?  Is there a post on lavag or on the darkside that lays out the benefits or pros and cons of this (using user events) vs just directly piping the "do" into a separate parallel queued state machine queue?  

[hooovahh]

what mechanism do you use to execute the "do" portion of code that could hold up the event structure?   

It does depend, but generally I read the event data in the event structure, and in it some information says what case in the state machine it needs to go to.  There it can perform the steps, or go to other states in the state machine to do the steps, associated with the event requested to be done.

 

After the QMH states are empty it comes back around to the event structure, to look for user events (or other events) to perform that may or may not have been generated while it was performing the Do steps from the last event.  Events are a lossless queue (for the most part) and so I don't really see a need to pull event requests, just to send them to another loop when they could just be handled in that loop, and have the events pile up.  Assuming events can be handled as fast as they are added.  But even if they couldn't, sending it to another loop wouldn't fix that.  Of course in 2013 there are new tools to detect if events have piled up to the point that there isn't hope of processing them fast enough.

 

A pros and cons list might be based on how it is implemented, and how it is used.  I list a con, but that might be contingent on the fact that the architecture is used in a certain way.  I think this would be a good subject to discuss either here or the dark side.