If RecursionLimiter is to “limit recursion”, it will do just that, and nothing more. Say FunctionA calls itself, that would involve a recursion depth. Say FunctionA calls FunctionB, that would be call depth alone, not recursion. (Call depth or recursion depth all employ a “call stack” to keep track of scope. Hence my mention of call stack depth. I understand that using a counter like RecursionLimiter does is a cheap and efficient compromise between true cyclic loop catcher and fast cyclic loop preventer).
In short, recursion depth involves call depth (since FunctionA is calling FunctionA itself). But call depth, in general, does not necessarily equate to recursion depth. That is, recursion depth is a special form of call depth.
RecursionLimiter currently limits call depth, not just recursion depth.
My proposal for animation requires that TriggerAction be runnable in a separate thread. The meat of the proposal was written here, though there are some minor errors in that proposal.
If each TriggerAction can run in a separate thread, and can also loop at a timed interval (proposal termed this as “Repetition Interval”), that would mean this: Each TriggerAction effectively represents a single animation loop.
Now, why would that implicate RecursionLimiter? If there are more than 50 animation loops (via 50 TriggerAction(s)), RecursionLimiter will balk. Even without my proposal for “TriggerAction as Animation Thread”, RecursionLimiter still should be corrected to do what its name implies.
With timed intervals, animation speed will be deterministic.
Anything from animating a movement (thus possibly removing the need for movement trail), to animating a counter endlessly to show status (eg, rotating clockwise means something, and counter-clockwise means something else).
Hence, this part of my proposal:
Add a new checkbox to TriggerAction: “Non-blocking”.
When user ticks this checkbox:
[]Advise end-users:
[list]
[]Race conditions might occur[/]
[]Proper thread programming is required[/]
[]Please limit execution time of thread (for performance considerations)[/]
[/:m][/list:u]
