Asynchronous enqueue with delay

[TiTou]

I recently started using this in one of my DQMH modules, it's a tiny feature and could be added to the DQMH palette.

The idea is to spawn a dynamic VI (using call and forget) that will wait a certain time (delay) and then enqueue a message in the MHL queue.

It allows to not block the MHL for other actions and make sure that a message will be enqueued with a delay.

It consists in 2 VIs, here's a simple demo :

[Olivier-JOURDAN]

I'm not a big fan of this method.

It will work in the nominal case but can be a source of complex issues to deal with. 

I would better use a helper loop to deal with that. It's not dynamic. It stops as soon as the Stop Module is sent.

It's less generic but much more readable and debuggable.

[TiTou]

@Olivier I understand you concern.

it's certainly a bit rough around the edges some of your concerns can be addressed (handle the stop module)

the lack of clarity / debuggability it less addressable

my use of this is in a module that communicates over the network with another module, when network is down, make sure we recheck again in 10 seconds, if the module is stopped in the meantime... well I don't care too much for that, the enqueue would fail, the error would be lost, I'm happy with this behaviour

Doing this with a helper loop would require to share a status with the helper loop... meh

[Olivier-JOURDAN]

@TiTou I understand that your use case makes that you don't really care about what can happen in some conditions.

Concerning a new feature provided by DQMH we need to be as careful as we can to prevent users to misuse it. 

My personal feeling about your proposition is that it opens too many possibilities to do wrong things.

[drjdpowell]

If you want an existing example, Messenger Library has "Delayed Send" and "Send on next millisecond multiple".  These have been used for many years, though Oliver is not wrong to be wary of them.  Suggestions:

-- you need to poll the live status of your Queue, so that if your Module stops, your async VI will shut down.

-- Manage creation of your VI reference in the way the AF does (the way you show has a small timing hole)

[TiTou]

Thank you both for your comments.

@Olivier : I understand your point about preventing misuse.

@James : I'll make the improvements

[drjdpowell]

Here is my instructional video for Messenger Library on this technique.  I think I discuss a few of the potential weaknesses of it as compared to a "Metronome" (which is close to how a "Helper Loop" in DQMH would behave):

[mbaudot]

Hey TiTou, thank you so much for your trust in DQMH and for taking time out of your day to share your idea with us.

We believe this idea opens too many possibilities of misusing the framework and doing wrong things.

So, we decline this request, at least for the next DQMH version.

Again, thank you for your input; it is most appreciated. Please keep those ideas coming!