I currently have a setup that roughly conforms to what is described in this response by @DavidRutten. There are also some extra bells and whistles implemented for smart thread management.
Now, I have a component that needs to await input from two upstream components, both taking a long time and using their own background threads to compute the output. Right now a solution for the main component is triggered after the first background thread is finished, and then when the second background thread is finished a solution is triggered again.
From the end user point of view, triggering the main component twice is not ideal. Is there any way to mark the main component as “disabled” or some other way to temporarily prevent it from being solved right away after the first background thread is finished ? I need a way to do this WITHOUT blocking the UI thread.
I am able to do this for custom comopnents with a custom property but is there anyway to do this for a general GH_Component instance ?
And yes, its always 42!
Edit: Seems I’ve got it wrong. Nonetheless, you could check if the input is valid and only continue working on valid input. What bother me most, is that this whole async stuff disables the upstream-downstream logic of Grasshopper. And as such its never a well made implementation. I have a hard time in understanding in which situation this will be truly beneficial. If your logic diverges so much from Grasshopper logic, it might be a better idea to completely hook it off Grasshopper. What are you planning to do?
I already have an implementation equivalient to your example. The issues I faced were with a component depending on more than one upstream components that run background threads. After the first background thread is finished, downstream components are expired and recomputed, and then after the second background thread is finished, the expiration + recomputing happens again. For some heavy downstream components this is undesirable. It would be much faster and user friendly if recomputing happened only once after ALL the upstream background threads are finished.
After posting here, I tried out an implementation where I store the upstream background thread dependency information for each component in a static dictionary and decide whether or not to expire the component based on that dependency information. I just got this implementation to work yesterday, but there is still one glitch - it happens when using clusters. When I am inside the cluster, everything works as expected, but as soon as I click “save and close” the output doesn’t seem to come out of the cluster. The output parameter of the cluster stays “empty”. Any suggestions for fixing this problem ?
And yes, I do see that this is turning into a long and tedious deviation from the normal GH data flow logic. I do plan to eventually “unhook” this from GH, but for now I am trying to get this working. THanks for the help !!
