User Event return value

[wiebe@CARYA]

The idea is to add a return value option to user events:

If there are multiple event registrations, the return value is passed through them. Pretty much like existing filter event.

Optional icing on the cake:

Spoiler

The Generate user event could be split up in a send and receive part.

A time out could be added to the receive as well. 

Waiting for return data could be optional. The data will still propagate though all registered event structures. 

Disclaimer

Spoiler

I've read all "User Event" search hits on the idea exchange. Closest\only related one I could find was Register-User-Event-as-Filter-event, which is mostly concerned about discarding the event. But the idea exchange search is terrible, so it could be right under my nose...

[Intaris]

Why would firing a specific event (with or without return channel - my return channel happens to be a notifier which is private to that message and whose lifetime is inherently tied to the lifetime of the work being done) not be equivalent to "You, specific person, do this now, and reply when done. Use this self-addressed stamped envelope for your reply."?

We use this to optionally fire up other event states (event-based "queued" message handler) only to send back the value when all states have finished executing. This is not possible if the return value is inherenty tied to the execution lifetime of the single receiving case. This tight coupling of single event and return value timing would be a major down-side for us. I would want full control over when the return message is sent. I don't have that with this proposal. With embedded notifiers in the Event, I do.

[wiebe@CARYA]

Because that's not what I'm trying to do.

I'm doing this: "Hey, group of unknown size and unspecified people, do this, and reply when you're all done".

• What if there are 0 listeners? You'd be waiting forever on a notification.
• What if there are n listeners, and n is unknown? How long will you wait for notifications?
• What if you expect n listeners, and one stopped? You'd be waiting forever (or a time out).
• What if one listener depends on other results? For instance, you could pass a value "task done". Each listener (0..n, unknown) will try to do the task if it's not done already. If it is done, pass previous results. Of course this can probably be done with yet another queue, DVR, or whatever reference... This would get you a quick chain of responsibilities. But it could be simple.

Even in situations where you can use a notifier, you wouldn't have to anymore.

A composite class, composed of children that perform the filter\task\whatever sequentially would do this. But the dynamics would be very different. To change the composite, a queue, user event, DRV would be needed. With user events, the sender doesn't need to care. Clients can simply be added or removed, from 0..n clients. At the expense of the order of execution.

In my previous two examples, how would that work with a notifier and flexible clients?

[wiebe@CARYA]

>Why even use events for this?

>Events would not be my method of choice for this use case. Why not use an action engine with "register" and "unregister" and "filter" capabilities for individual actions (VI refs, OOP, whatever)? Then simply call the action engine in your UI filter event....

Because action engines are globals.

If I used an action engine in a VI, and cloned the VI, they will communicate. Of course, solvable with more complexity.

[wiebe@CARYA]

> I sure hope somebody is listening to me and will do that thing, and will reply when they're done.  I'll just wait here and hope."  Real Requests are like "You, specific person, do this now, and reply when done."

No, the point is the sender doesn't need to know who is listening at all.

It's much more like "I have a request. Everyone do your thing, and let me know".

For a key filter, I don't care if there is a filter. If there is, keys will be filtered. If there isn't, keys won't be filtered.

If keys should be filtered, but aren't, or vice versa, you made a bad program.

I still think it's way more easy to screw up the program if you need to keep using notifiers, (functional) globals, other user events, and other workarounds.

More code == more bugs. Statistically, of course.

[wiebe@CARYA]

And for the record, if this was an option, you wouldn't be forced to use it.

But it would be there if you'd ever needed it.

Just one more tool. To be used when appropriate, replacing X other tools...

Anyway, I've have some boiler plates to program...

[drjdpowell]

---

---

Why would firing a specific event ... not be equivalent to "You, specific person, do this now..."?

Because Events have no concept of "You, specific person".  Events are fired off into the ether, they are not addressed to anyone.  Noone may be registered for them, or unknown numbers of unknown parties may be registered; the sender of the message does not know, and relies on higher-level code to have ensured the right parties have been registered for their messages.

Register-Notify, that Events are based on, is really for "Here is some info that others might (or might not) want".  But a Request is "I need you to do something for me".  This requires there be a "you", a reference/address to an entity.  Combining the two gets you "Here is a request, that others might (or might not) want to fulfill, assuming somebody is listening".

Now you can bend the Event system to serve as addresses, by making the event receiver create the event, and be the only one registered.  Then a User Event is the address of a specific receiver (and that's how about 90% of my "actors" in "Messenger Library" communicate. Possibly, you are doing that, but the OP is specifically trying to deal with 0 to N unknown number of subscribers.  

[drjdpowell]

> I sure hope somebody is listening to me and will do that thing, and will reply when they're done.  I'll just wait here and hope."  Real Requests are like "You, specific person, do this now, and reply when done."

No, the point is the sender doesn't need to know who is listening at all.

It's much more like "I have a request. Everyone do your thing, and let me know".

I understand your idea, using a "(Blocking) Round-Robin Request Reply" messaging pattern to deal with an unknown number of subscribers, but I think it is a limited-use pattern.  

And for the record, if this was an option, you wouldn't be forced to use it.

But it would be there if you'd ever needed it.

Just one more tool. To be used when appropriate, replacing X other tools...

I disagree with the idea of a large toolbox of weak tools used in a mix-match-and-duct-tape fashion.   You need a limited set of effective tools.  

[wiebe@CARYA]

>Why would firing a specific event ... not be equivalent to "You, specific person, do this now..."?

Because Events have no concept of "You, specific person".  Events are fired off into the ether, they are not addressed to anyone.  None may be registered for them, or unknown numbers of unknown parties may be registered; the sender of the message does not know, and relies on higher-level code to have ensured the right parties have been registered for their messages.

No argument there...

With filter events, the sender does get the result though. After all registered got the subsequent results.

>Register-Notify, that Events are based on, is really for "Here is some info that others might (or might not) want".  But a Request is "I need you to do something for me".  This requires there be a "you", a reference/address to an entity.  Combining the two gets you "Here is a request, that others might (or might not) want to fulfill, assuming somebody is listening".

It works if nobody is listening.

If it was a send\reply mechanism, you'd be right. But you're receiving the same data type as you're sending. So if there is no listener, you get the original data back.

So I guess this is not a request mechanism? I don't think I called it that.

It's exactly what a control does when you press a button. It sends out a Key Down? event. It's not a request. It works if nobody is listening. It works if 10 are listening. The control doesn't care. It does get the results.

>Now you can bend the Event system to serve as addresses, by making the event receiver create the event, and be the only one registered.  Then a User Event is the address of a specific receiver (and that's how about 90% of my "actors" in "Messenger Library" communicate.

More code...

I can work around this just fine. It's WoT, but I'll get it working with one of the stock boiler plates.

>Possibly, you are doing that, but the OP is specifically trying to deal with 0 to N unknown number of subscribers.  

Yes, there doesn't need to be a reply.

The event mechanism handles this just fine for filtering events.

Besides the Discard?, all I'm asking for is a way to get filter event like behavior without having to write lots of code, that is hard to make fail safe, and probably never is.

[wiebe@CARYA]

> I sure hope somebody is listening to me and will do that thing, and will reply when they're done.  I'll just wait here and hope."  Real Requests are like "You, specific person, do this now, and reply when done."

No, the point is the sender doesn't need to know who is listening at all.

It's much more like "I have a request. Everyone do your thing, and let me know".

I understand your idea, using a "(Blocking) Round-Robin Request Reply" messaging pattern to deal with an unknown number of subscribers, but I think it is a limited-use pattern.  

And for the record, if this was an option, you wouldn't be forced to use it.

But it would be there if you'd ever needed it.

Just one more tool. To be used when appropriate, replacing X other tools...

I disagree with the idea of a large toolbox of weak tools used in a mix-match-and-duct-tape fashion.   You need a limited set of effective tools.  

The usages is limited.

But when needed, and do I need it, it will save lots of work or code.

So... Where are the effective tools?  Not in LabVIEW? I really don't want to add an entire messaging library, just to get a simple functionality working.

I doubt very much that a library will get exactly this behavior. It's simply missing. If AF or your library does this, it won't be trivial.

[Intaris]

I'm doing this: "Hey, group of unknown size and unspecified people, do this, and reply when you're all done"

So who defines "this".

That is, who presents the API for the functionality. That is who implements the optional filtering. That is who is aware of whether anyone has added filters or not. And, in the case of a non-LV-Native solution, does the work of maintining that filter list.

It's got nothing to do with the sender at all. Whether you use Queues, Notifiers, Events or whatever.

If there are 0 listeners, there's no "this" and the request fails. "this" only becomes an actual thing when there is at least 1 listener. In your case, "this" is "Key Down" (tied to a UI action), NOT "Key Down?".

In my previous two examples, how would that work with a notifier and flexible clients?

Module X creates and registers for Event "Key Down". Module X offers a way to add/remove filters for this event (user code). The EventData for "Key Down" includes a notifier (datatype not tied to the input data of the event). Module X makes this User Event available via some otherwise unspeficied path.

Another module Y accesses this information, sends an Event "Key Down" to Module X. An integral part of sending this event is creating a new notifier (If it wishes to receive a return value) and sending this notifier refnum as part of the Event Data. Module X receives the event, filters according to whatever filters are present (via whichever method it wishes) and when finished sends data back via Notifier to the module Y. Module Y defines how long it is willing to wait for the data. Once Module Y has either received the return values via notifier or it has timed out, it destroys the notifier.