Get remaining time when futures redeemed
Issue #70
new
Hello,
One thing that I do on occasion is basically chain some operations together with futures. So scatter some messages out, then await them with a timeout, then use those results to send more messages and then await those messages with a future & timeout. This works pretty well, but one minor request I have is getting the remaining time of futures out so that I can have a total timeout for all futures.
This could be implemented on the user side by measuring time, but I think it would be best to just have the remaining time on an output terminal as well.
Basically something like this:
And for single token a tick count would be needed,
This works for the normal redeeming VIs, but the async actions would be harder to integrate this with. I personally don’t want it for the async redeeming actions, but other may? But I also think it is less needed though. The only reasonable way I can think of would be a breaking change that bundles it with the reply message, then using a helper VI similar to the “Read Result of Async File Dialog” VI to extract it.
Anyways this is mostly an idea as it’s fairly easily implemented in user code.
Comments (2)
-
repo owner
-
reporter
This would be useful in a couple of places, primarily when I am handling some collection of data that has an overall timeout, then each item in the collection would get the total timeout minus the time so far spent on the previous items. And yeah, if inlined DCE could get this. But I’m not sure the overhead would really matter outside of microbenchmarks.
The way I am doing it now is similar to how you describe it. I made a malleable VI that does this and works well.
- Log in to comment
Do you have an example that illustrates the usefulness of this technique? That of waiting on Futures, then based on that info using a new set of Futures, with an overall common timeout? My concerns here are:
Another option would be to put that little “Remaining Time” subVI on the Palette, to make it easier to do the timout calculation yourself. A bit more work, but arguably clearer code, and you would be able to include non-Future steps like subVI calls in the overall Timeout.