[DNM] Cancel Graph Execution

[aparajit-pratap]

Purpose

Recharge: Cancel Graph Execution Note: Unfortunately this doesn't work in Revit as D4R is single threaded and the UI is locked while the graph is running making it impossible to cancel the execution from the UI.

Declarations

Check these if you believe they are true

• [ ] The code base is in a better state after this PR
• [ ] Is documented according to the standards
• [ ] The level of testing this PR includes is appropriate
• [ ] User facing strings, if any, are extracted into *.resx files
• [ ] All tests pass using the self-service CI.
• [ ] Snapshot of UI changes, if any.
• [ ] Changes to the API follow Semantic Versioning, and are documented in the API Changes document.

Reviewers

FYIs

[mjkkirschner]

@aparajit-pratap just curious - is the description of this pr (does not work in Revit) still true - what was the state of the solution you did get half working there? It might be useful to consider it for other UI updates we want to do in other single threaded contexts - do you think it is applicable more generally?

[aparajit-pratap]

@mjkkirschner the solution where it is continuously polling for keyboard key state is not a robust solution as I've seen Revit crash at times unexpectedly. There are other times when one has to repeatedly press the Esc key hoping for the threads to switch context and be able to capture the keystroke event. This leads me to believe that aside from causing some performance hit it is also not a reliable solution that we can leverage for other single threaded contexts in general.

My guess is that a more reliable solution would be to write an out-of-proc application to send cancellation events to D4R or other Dynamo hosted application.

[dimven]

@aparajit-pratap I've been thinking about doing something similar for D4R. Would it be possible to add a cancel button on a separate non-modal UI that would overlay the main UI and control a bool flag? Then before each node's execution, the main thread would read the state of that flag. If the flag has been flipped, the execution would stop.

This way you won't be able to cancel an already started process that takes a really long time, but you'd be able to cancel execution right afterwards. Nor will this solve processes that have entered into an infinite loop. However it would still be very helpful in cases where you have multiple "slow" nodes throughout a graph.

[aparajit-pratap]

@dimven thanks for your comments. I think I tried something similar where I introduced a second thread that listened for keyboard events and then tried to send a cancellation event from it. However, while the main thread is running it would take some luck for this other thread to gain control and capture the keystroke event.

In your case are you thinking of running the new UI in a separate process or another thread. I suppose you might run into the same situation where the new UI is running on another thread and competing for control with the main thread but I could be wrong and it might be worth trying this solution too. I would be interested in knowing if it works and can help out if you get a PR started.

You are right about not being able to intercept a long running task in external code. We would have to wait until control is passed back to the Dynamo VM at the individual instruction level and then stop further instructions from being executed. This is what I've tried to do in this PR. It can also take care of replicated calls where we can cancel execution in between successive replicated calls.

One of the ways I can think of to have control over external code is to do something like our trace mechanism that we use for element binding - store the cancellation flag in TLS and then read it from anywhere to check if a cancellation has been requested. Again the onus would be on zero touch developers to add these checks to their nodes and exit if the flag is set.