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]

As part of the User Event API itself, no I would not want to see this at all.

Deadlocks are a logical consequence of this. Call a User Event within a structure which handles the event - deadlock.

If you want to get values back from your User Event then add a notifier with the required datatype to your User Event data structure and use that for the return values.

[Intaris]

This method is sometimes referred to as a "Self.-Addressed Sealed Envelope"

[wiebe@CARYA]

>If you want to get values back from your User Event then add a notifier with the required datatype to your User Event data structure and use that for the return values.

That doesn't work if you want return values from an unknown number of registered events...

The return value does, each registered event could add it's value to an array. 

The notifier also doesn't prevent deadlocks. If you send the event from the event structure, and wait for the notifier, the notifier doesn't fire if the event is handled in the same event structure. It just takes more effort to shoot yourself in the foot.

[AristosQueue (NI)]

Intaris and I are in complete agreement for the main part of your idea.

If the "optional icing on the cake" section is implemented, then the idea becomes barely palatable (that icing isn't quite good enough to make me eat burnt cake).

Under the main idea, if Generate is synchronously waiting for results, this feature would be a lethal bug waiting to happen -- and I say that with direct experience of being called into investigate the failures of so many messaging frameworks over the years. My general conclusion: synchronous messaging is bad.

Under the icing idea, if Generate returns a new refnum that a later node can use to wait for a response (similar to Asynch Call By Reference), then it becomes possible to separate the two efforts, but many people would probably just use the two nodes serially, leading to the same result. Setting up a response system between two async processes is hard, but I think this idea just makes it harder under the guise of making it easier.

(Note: Asynch Call By Reference is a *call* to a unique process that isn't doing anything else. That makes it distinctly different from a *message* to an already-running process. Thus my good/bad evaluation criteria are different.)

[wiebe@CARYA]

It would open opportunities. Haven't heard a good alternative that works when the number of registered clients is unknown.

If you'd use it in a stupid way, you'll get stupid results.

Guess it's "power to the programmer" versus "protect the noobs" once more...

Never got Asynch Call By Reference working stably. It either hangs my classes (being edited in another context) or crashes LabVIEW. My expectations might be wrong...

[AristosQueue (NI)]

The part of the idea about feeding the data from one registered structure to the other would also require changing event handling so that those ideas are processed sequentially. Today, handlers of the same event run in parallel, as you can test with code like shown below -- both numerics will increment together.

[AristosQueue (NI)]

> Guess it's "power to the programmer"

> versus "protect the noobs" once more...

Were you trying to make me laugh? You succeeded.

No.

The power programmers were (are) the ones building the messaging frameworks. They were the ones losing months of work to bugs they could not explain. They were the ones begging for something better.

The novice programmers weren't even involved.

[wiebe@CARYA]

LabVIEW's filter events get called sequential.

You can register multiple Key Down? events, and each get's it's data from the previous.

Typing an "a' will result in "d", "a" + 3.

[Intaris]

It would open opportunities. Haven't heard a good alternative that works when the number of registered clients is unknown

Sorry, what does this actually have to do with the idea as posted? I think I may have misunderstood.

This is a 1:1 idea, not a 1:N idea as I see it. Only the process which actually sends the User Event receives and data back. Broadcasting to multiple subscribers (known or unknown) is moving into MVC territory.

A large drawback I see with this idea is that, even if the synchronous event would be nice (which IMHO, in this form, it is not) limiting the return data to the same format as the sent data is extremely limiting. Sometimes I want to send something else back other than the data I just sent..... Hence notifiers.

The problem with passing data from one handler to another like filter events is that you don't have any kind of explicit control over the order. Sure, they're serial, but not all operations you might want to perform are commutative.

[Intaris]

Maybe the problems I'm generally dealing with are so different to yours that I have trouble seeing the benefit of this at all..... Care to outline a specific use-case?