is it planned in the next updates to grasshopper3d the development of an emergency stop button to interrupt the execution of a GH definition which does not end because it takes too long to execute?
1 Like
Rhino/GH is incredibly stupid about being interrupted when it is thrashing helplessly. Closing the Windows task and restarting Rhino is the only way to kill it. Routine procedure, happens all the time. 
This is very relative, it depends on what you’re doing. Real-time solutions and those that take 10 minutes can be equally valid, depending on what you are doing.
GH already has an abort system by pressing the escape key but it only works when the solver is going to the next component to be run. If the problem comes within a component there is nothing to do. If the problem is in a context where the solution repeats continuously (until some criteria is reached, as in kangaroo), handling this abortion is terrible. This works badly and in GH1 there’s not much to do because the processing of the document/components and the interface run in the same thread, and you have to wait for the solution to finish (if it does finish) before you can interact with the canvas. I think the solution will be allowed by separating that, I don’t know if GH2 will be able to handle this.
However, it’s not that much of a problem to force the closing of Rhino and GH if you just load the plugins you use, even though it’s annoying it’s not that long. And to avoid losing unsaved work, you can use this:
Another alternative is an input evaluation system that compares the expected use with the given use to anticipate if something might go wrong. But although the idea is simple, I don’t think the implementation is, because of the same problem of relativity. We don’t all have the same hardware, we don’t all use GH for the same thing, and perhaps the remedy will end up being worse (forcing the user to interact by asking him if he wants to continue if it anticipates excessive computing) than the disease, which rarely occurs if you know what you are doing.
1 Like
Some Grasshopper component and calculation between components implements an Escape key logic that will terminate the definition immediately. However, a large part of non-responsiveness happens during external geometric call to Rhino, it is hard to be prevented right now as for the single-threaded infrastucture of Rhinoceros.
Ad: Pancake has a “Hang Protection” feature that do an emergency save if your GH has stopped responding for more than 1 minute.
1 Like
What’s the state of this today?
It’s a completely safe assumption that every system running Rhino 8 and Grasshopper has multiple CPUs. And given the advances in OS architecture to support such systems, it seems like bad practice to lock up the main UI thread with much of anything besides UI updates. On modern computers, the UI should never become unresponsive. If it does, a watchdog timer should kill the process with the assumption that something has gone wrong.
Maybe I’m just spoiled from developing on iOS where you are practically forced to keep large workloads off the UI thread.
Sorry if this (discussion) thread is long dead. I’m new to Rhino and GH and just Googled this after I connected a wire that blocked the UI for just over a minute. I thought surely there must be a way to interrupt the calculation (like ctrl+c in the terminal). Instead, I got the rainbow beachball (I’m on Mac).
3 Likes
This could be amazing !
I cannot count how many times I had to restart rhino just for plugging the wrong wire in Grasshopper.
Endless ammount of wasted time and frustration.
1 Like
+1
Any plans for something like this? Sometimes working in GH is like walking on eggshells in a bad relationship.
1 Like