Jump to content

Event Structure vs. Variant Queues


Recommended Posts

QUOTE(crelf @ Jan 29 2008, 12:31 PM)

That's the important point right there (emphasis added for emphasis) - and something I didn't know. Is this true, even when the event structures are on different targets? :wacko:
That I don't know. Until you asked the question, I didn't know you could register to listen for events that happened on another machine (or other app instance). My guess is that the other machine sends events to this machine, and those events merge into the regular event queue and are thereafter subject to the same handling rules. But I severely doubt that the other machine is holding waiting for any "I'm done" message to come back.

You should test this.

Link to comment

QUOTE(Aristos Queue @ Jan 29 2008, 05:33 PM)

Essentially, yes. Events are *always* fully handled in the order they occur. So if you have two separate event structures registered for separate events, and both events occur, the first to occur will finish its event case before the next one begins being handled, even if these are separate event structures. This is important in case the event structures are accessing common queues, global storage, hardware or other refnum type. If multiple event structures are handling the same event, then all of them must finish handling the event before the next one begins being handled.

Ouch ! That would have been something I would have certainly fallen foul of - I can easily imagine a system with two 'quick' events being broadcast to multiple event structures, but one of the event structures being busy doing a longer task when the events are fired and me wondering why *none* of my event structures got the second event in a timely fashion....

Link to comment

QUOTE(Aristos Queue @ Jan 29 2008, 09:33 AM)

QUOTE(Gavin Burnell @ Jan 29 2008, 12:39 PM)

Ouch ! That would have been something I would have certainly fallen foul of - I can easily imagine a system with two 'quick' events being broadcast to multiple event structures, but one of the event structures being busy doing a longer task when the events are fired and me wondering why *none* of my event structures got the second event in a timely fashion....

Which is just another very good reason to make the event structures complete as fast as possible. It would be best to use the event structures as simply structures that filter incoming events. Pass the work to a separate loop and leave the event structure nice and lean.

Link to comment

Hi All,

I am not sure if the question here is whether or not user events can be handled by multiple event structures executing in parallel. If this is the question, then I believe that the answer is that it can be done even if one of the event structures is being held up. I have attached an example that I believe demonstrates this.

... sorry for the ugly code....

Thanks,

Mike

Link to comment

QUOTE(Aristos Queue @ Jan 29 2008, 06:33 PM)

QUOTE(mrak1 @ Jan 29 2008, 10:34 PM)

I am not sure if the question here is whether or not user events can be handled by multiple event structures executing in parallel. If this is the question, then I believe that the answer is that it can be done even if one of the event structures is being held up. I have attached an example that I believe demonstrates this.

AQ is wrong (sorry), the code from Mike shows that the top loop is considerably slower.

If you add the 'Exit Button\Change Event' to stop the loop you will understand why you need to finish an event handler fast.

Ton

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.