Event Registration: Cluster vs. Individuals

[CoastalMaineBird]

I have a piece of code called a "Receiver".  

It listens on a TCP connection for various messages from a PXI box.

There are about 30-40 different types of messages, some with large payloads, some with small.

The receiver decodes which message came in, and triggers a custom USER EVENT.

Thus there are 30-40 user events possible.

The receiver CONTROLLER is a piece of code that creates the events, and it puts them into a cluster.

Whoever wants to can read this cluster, pick out the events they're interested in, and register them for an event loop.

I have several different places in my code where I have event loops, based on which window the user has up.

Each window is NOT interested in ALL the events, only certain ones. 

So, I've always done it like the top part of this picture shows, I unbundle the events I want, and register them.

I found out (by accident), that I can just connect the whole cluster to the REGISTER EVENTS function, and not have to pick and choose.

My question is:  Is there a downside to that, in terms of speed or memory usage or something? 

One of the events is occurring at 10 Hz, but I don't need to know about that in my window loops (it goes elsewhere), so the EVENT structure wouldn't have a case for it.

Does it hurt to register for that event, when I'm not interested? 

 

Message Edited by CoastalMaineBird on 05-13-2009 07:15 AM

[Ben]

Coffee still engaging so take with a grain of salt.

Provided

1) You are not using filter events (where the order of the registration determines the order in whcih the various event strutres will recieve the event and the possibility that an earlier filter event could dismiss an event expected  by one of the others)

and

2) All of the events structures that are registered are allowed to fire (preventing a build up of Events waiting to be servided)

You should be OK.

Ben

[tst]

I think there should be no problem with it.

The following code fires a non-registered event repeatedly. If there is no wait, RAM is consumed rapidly (probably because the event loop doesn't get the time to clear the queue), but if you add a wait every X loops, the RAM seems to be stable. This doesn't test using the same event in more than one event structure, but I think it's representative.

[CoastalMaineBird]

1) You are not using filter events (where the order of the registration determines the order in whcih the various event strutres will recieve the event and the possibility that an earlier filter event could dismiss an event expected  by one of the others)

All these events are notification only - no filters involved. 

2) All of the events structures that are registered are allowed to fire (preventing a build up of Events waiting to be servided)

- I don't understand what that means.  The Receiver "fires" the event when the associated message is received. But not every event will fire - there's one for an error, for example. That one rarely fires.

What is it that disallows an event from firing, in your statement?

Thanks, 

[Ben]

---

CoastalMaineBird wrote:

...

2) All of the events structures that are registered are allowed to fire (preventing a build up of Events waiting to be servided)

- I don't understand what that means.  The Receiver "fires" the event when the associated message is received. But not every event will fire - there's one for an error, for example. That one rarely fires.

What is it that disallows an event from firing, in your statement?

Thanks, 

---

Imagine a state machine with two states "handle events" (with an event struture) and "wast time". If the State machine is stuck in the "waste time" state, the event sturture in the non-executing state "handle events" will have a queue of event building up that are waiting to be fired.

I would assume that you are not developing using that structure so it probably does not apply to you.

Take care,

Ben

[CoastalMaineBird]

I see. I think of "fire" meaning the GENERATE USER EVENT function.

Your definition is "execute an event structure".

In my case, I have a data "recorder" which has it's own event loop, registers for the DATA UPDATE event, and doesn't care about anything else.

The various windows which come up have their own loops which do NOT care about the DATA UPDATE event, but DO care about various others.

So there's no way for an event to be generated without SOMEBODY executing an event structure, although it's possible no one is interested in a particular event at this time.

Basically , what I'm hearing is that there's no significant difference between registering for individuals, and registering for the whole group.

I was thinking that maybe, if I register for event X, but don't have a case for event X, then that takes up processing time in the EVENT structure when X happens, whereas if I don't register for it, then the EVENT structure doesn't even notice.

[tst]

Did you see my post?

[CoastalMaineBird]

Yes, and thanks.

I see what you mean about taking up memory.  I don't think that's applicable in my case, since I'm generating events at 10 Hz + sporadic others, so I think there's time to handle things.

But it's still not 100% clear: does the registered event suffer because of all the unregistered ones going on?