A new channel template: Event Messenger

[AristosQueue (NI)]

Heh... there's even a test case in the test suite from Jeff to assert that last elt is false on abort. So it is deliberate. I'll make this one match.

[AristosQueue (NI)]

New version posted.

[sth]

Bob_Schor wrote:

This is a reply to Sth's about the Channel Reader being outside the Event Loop, suggesting that the Channel passes Events and the Event Loop processes the data.  He then ask if the Channel only transmits data once.

I've played with the Examples, and have made an Event Messenger myself, so here's my take on things.  Yes, the Channel passes Events and the Event Loop processes the data.  However, every Write to the Channel causes data to by put into the Event Loop's Queue (where it is handled just as in a more common Queue, in the order received.

Here's how I conceptualize this.  The creation of the Channel Reader and wiring it to the Dynamic Event node both adds the <channel value>:User Event as a possible choice for the Event Structure, and also creates (behind the scenes) what used to be the User Event Queue.  Calling the Channel Writer puts things onto this Queue, where they are transferred to the User Event Queue "in the order received" (I'm not sure these take place as separate steps, but it helps me to think about it in this way).  I've done a little test routine that shows that you can have the Event Loop running before you put anything into the Event Messager Writer, just as you can have an Event Loop that process Button Pushes before you generate any User Events (in the non-Channel Dynamic Events).

Bob Schor

Agreed, but putting the subsequent data in the Event Queue is not actually putting anything into the channel?  I think the channel reader creates the standard User Event and registers it.  Passes that event to the event handling loop.  I have no idea what a second read in a loop would read back from that read channel endpoint.  The first call to the write endpoint will create the user event and register it.

Each write (after the first?) on that channel actually just executes a "Fire User Even" with the data written to the channel AND the booleans last element and abort as part of a cluster.  In those subsequent writes to the channel nothing is made available at the read.  Data is actually diverted to the standard event queue for that event structure.

I haven't had time to disect the code, but if I have two loops generating events (ie writing on differnt event channels) is there a name conflict when those events go to the same event loop?  So if I have multiple event generators going to the same event consumer loop?

Obviously I need to unpack and play with this.  Sounds interesting!

[AristosQueue (NI)]

sth wrote:

AQ, usual question....  What patch level do I need for Mac OS X?  Or linux?

I didn't call Windows out special. F1 for everyone.

[EDIT] I just realized why you're asking... the links were provided to me by another dev... I didn't realize that the other platforms weren't at those links. I'll modify the link.

[rkmadse]

What is the Channel Wires equivalent to adding a priority message to the pipeline? Is there a way to add a message to the top of the queue so it's executed first? I'm trying to create a QMH type producer consumer architecture but am not thinking that if I can't add a STOP to the front of the queue then it may not do me any good to try and migrate to Channel wires. Thoughts?

[jkodosky]

The current messenger channel uses a simple queue, but it could be enhanced to use a priority queue.  We had left that as an exercise for the community but maybe we should incorporate a priority queue in some future release.

While I can appreciate that some find it useful to be able to push something onto the front of a queue, I've always thought this was problematic design.  In a client-server application, allowing the server to enqueue things at the front, e.g., as a simple way to schedule multiple sub-steps, is a clever solution until you try to expand the system to have multiple servers.

The abort capability was added to Channels specifically to address the emergency stop case, but maybe it's too draconian.  Other options are possible, short of implementing a full priority queue in the messenger channel, and maybe it's worthwhile to explore various use cases to see what is needed.

[drjdpowell]

I'm someone who would argue against using priority in a message queue at all.  Though just using it for an "emergency stop" is not bad, assuming there are no messages that absolutely must be handled (which could be a dangerous assumption).

[Ben]

---

@drjdpowell wrote:

I'm someone who would argue against using priority in a message queue at all.  Though just using it for an "emergency stop" is not bad, assuming there are no messages that absolutely must be handled (which could be a dangerous assumption).

---

I strongly agree.

I have had multiple QSM's show up on my development machine that have used the option to push states in the front end of queues for similar reasons. While I can understand that developers that go back to the days of single thread application and are comfortable with the ideas of "pushing" and "popping" onto or off of stacks, what happens with the abuse of pushing on to the front of a queue for a QSM is LabVIEW's version of "go-sub" and chaos which even Dhijkstra railed against. In short, we can never be sure in exactly what order things will be processed.

If we need a method to pre-empt, add another channel/queue to do exactly that.

edit: Correction

It was the "Goto" that Dhijkstra said introduced chaos. Sorry, post before coffee was engaged.  

Ben

[rkmadse]

Since I can't dig into your code... what happens if there is an error in your producer and consumer logging loops (Triax I think you call them..)? 

To me it looks like if there is an error then you exit the "Triax" Producer somehow, and then the error is added to the message queue so it transitions to handling an error and exits everything? Is that correct?