WISH : Ability to crash GH without crashing Rhino

It just takes forgetting to graft a list and plugging it downstream to induce overwhelming computation.
Also, using Kangaroo can lead to overlong (possibly infinite) computing.
So yes, I often need to crash GH to get moving forward and fix the issues.
It would be great if it didn’t require to crash Rhino as well.


we all wish that


Sometimes (again: sometimes) it helps to keep esc button pressed for long 10 seconds or so.

This is because each component uses a “Cancellation Token”. It will check before the component computes a run if the user wants to abort by e.g. pressing the ESC button. This works well in those cases where the component performs more runs with smaller computations. But in those cases where Rhino is stuck by doing a heavy calculation (such as Boolean operation on complex data), this does not help.
The problem is also often part of script components or plugins, because the code does not consider any abortion mechanism. There is a lot of benefit of running GH in the same process with Rhino, but as a GUI they need to share the same main thread and this is a disadvantage if you need to kill/abort something.
Maybe the most realistic workaround around are Hops definitions, since they run a dedicated Rhino.Compute instance… But I think its quite unrealistic to expect much better for GH1.

Hi Tom, what are these ?

This is interesting. Maybe if that cancellation token gets converted to a disable solver switch…



“Hops lets you increase the legibility of your code by simplifying complex definitions, reducing duplication, and sharing and reusing functions. Hops lets you solve functions in parallel, potentially speeding up large projects. It also lets you solve functions asynchronously, without blocking Rhino and Grasshopper interactions”

“Behind the scenes, the Hops client passes the Grasshopper definition you specify to a headless instance of Rhino and Grasshopper server.”

So essentially this means any definition running in a Hops “container” will be dedicated. Now I don’t know what happens when one instance is aborted, but essentially this should not kill the main RH/GH instance. I think if it still does, it should be fixed to allow this. But essentially the idea is that a GH definition runs with a dedicated headless Rhino instance, giving the ability to kill parts, without killing the host.
I have to admit, that I did not try it myself yet.

Sounds like what Clusters should have been from the beginning…

I think that the magic here is Rhino.Compute, with that came the idea of Hops. I think if this would have been doable 15 years ago, Grasshopper may have been created as dedicated application from beginning on…

We can continue to try and find ways to cancel computations in GH, but in some ways the answer to this request is GH2. GH2 was designed with this concept of being able to cancel as part of the core architecture.


where is GH2? everyone here will retire before it becomes useful for any actual work.

1 Like

It’s available via the package manager. Make sure to include the “include pre-releases” checkbox in the package manager. It’s under active development.

Hi Andy, in relation to this thread, I think that the new “Egg crate” system is very likely to generate never-ending computations when one accidentally caches/bakes a huge quantity of objects.
One more reason to have some kind of emergency stop button.