Stopping a time-delayed message

[drjdpowell]

AristosQueue wrote:

I've thought about deprecating it for something new, but it also has seen so little use that I haven't made it a priority.

I would have thought it would get quite a bit of use for timing periodic actions, such as TimBotsM's measurement samples.  I use a "Metronome" actor (non-AF) quite a lot, and I think Daklu has a similar component.  You can do the equivalent, I imagine, with extra message-sending loops in Actor Core, but having a reusable component is valuable.

[drjdpowell]

TimBotsM wrote:

Well I certainly hope you arn't gonna remove it since it's an ideal tool for me.

I use the time-delayed message to sample a measurement device every 2 seconds.

A metronome actor would be better; you could send it a message to change its period on the fly.

[KuGr]

Oh no, don't depricate it.

Super useful, though I have wrapped it in a class and added the ability to change its timing (including pause it) and I can change the message it sends.

Perhaps this is a good thread to talk about its future instead of its demise. How would we like to see it evolve based on our current use.

The idea of building it as an actor is a possiility, though we would need the ability to change the wait time on the queue.  I am OK with the notifier aproach.

[fredb]

AristosQueue wrote:

drjdpowell wrote:

(why isn't this an actor already, BTW?)

I've thought about deprecating it for something new, but it also has seen so little use that I haven't made it a priority.

Not sure how you are determining the amount of use the timed msg is getting. It is (I believe) a necessary element of the framework. I suspect, like me - several built their own version of it before you added it.

What am I missing regarding stopping a timed delayed message? Isn't this true, in general, of the entire framework? Race conditions can be designed in (I have perfected the art form!). And then designed out (still working on that one). And, if one extra [timed delayed] message is sent, and no one is there to catch it, does it matter? Good design suggests no. Unless the message has to be caught (Fire! - turn on the sprinklers) - in which case the fire dept. better be on the line to get the call.

[AristosQueue (NI)]

I say little use because

a) it has received few comments on the forums

b) at one point, the version of it that I put up available online was broken for a couple months and no one mentioned it.

I have seen a number of people write metronome-like actors, but my perception has been that they were specific to their apps and had some reason to have to be specific. But perhaps that's not true. We can certainly take that as a thing to improve over the next round of revisions.

[AristosQueue (NI)]

TimBotsM wrote:

Well I certainly hope you arn't gonna remove it since it's an ideal tool for me.

I use the time-delayed message to sample a measurement device every 2 seconds.

We wouldn't remove the functionality. We'd maintain the functionality with a different function call -- one that would enable a much wider range of use cases in addition to the ones it has today.

And deprecation means that we wouldn't immediately (and maybe not ever since it is cheap to keep) remove the function itself, just delete it from the palettes and add a note that there's a new API for the same functionality.

[justACS]

The new AF course material I am developing includes an example that uses the Time Delayed Message to create a metronome.  I think it's a great alternative to making customers drop a helper loop into Actor Core.vi.  It's certainly lighter weight than creating an actor and all of its message classes (you'd need four, if memeory serves) especially since that actor would wind up implementing essentially the same code.  I'd hate to see it go.

[drjdpowell]

fredb wrote:

What am I missing regarding stopping a timed delayed message? Isn't this true, in general, of the entire framework? Race conditions can be designed in (I have perfected the art form!). And then designed out (still working on that one).

The problem is if you want to do the following: end the repeated sending of MessageA and then send MessageB.  The "and then" part isn't possible, because you can't know for sure if another MessageA is coming after you trigger the notifier.  You can wait a couple ms and be almost 100% sure, but that is actually bad, because it means the case of an additional MessageA after MessageB may never happen during testing, thus if this causes a bug this will happen in actual use.  Very rare bugs are worse than those that happen often, as the later bugs are quickly corrected.

This is not true in general with the framework, because an Actor can send you a message to tell you when it has stopped doing something.

[AristosQueue (NI)]

Wouldn't be deleting it. More something like the attached. (Saved in LV 2013.)

"Start Message Metonome.vi" has the same conpane as the existing "Time-Delated Send Message.vi" except instead of a Notifier output it has a Message Queue output. I didn't add all the messages for "skip next message", but those are trivial to add. What I did add was some of the messages that you can't do with the existing model.

I don't promise that it is bug free. This is "Friday afternoon had a spare moment between meetings" code.

PS: This version can be monitored for the Last Ack message by the caller, which addresses Powell's point.

[fredb]

Ahhh! The last line of your reply clears it all up. That makes perfect sense. So a [optional?] sync on stopping a time delayed message?