Open
Description
Hello, I'm trying to see what efforts would be needed to port to V3 and look at the changes I've done in the core logic so far: I was wondering what would be the best strategy to handle long computations? Right now the UI hangs if anything takes a long time to compute in a node.
Example: just add a Sleep of 10 seconds in one of the compute() function in the calculator example to see what I'm experiencing.
In my previous implementation I created WorkerNodeDataModels and workers but I'm not sure it's the best strategy (what happens when you have multiple inputs, what do you do with current long computation, etc etc...) and was wondering if this is something you thought about?
Activity
paceholder commentedon Nov 17, 2024
Hello,
I never tried to work-around similar cases.
Maybe you could spawn a thread when your node is about to compute something and observe the fishish of the thread?
Isn't it what you did before?
Or didn't I get you actual problem with the version 3?
Thanks
Dimitry
florian-ts3d commentedon Nov 18, 2024
Yes this is more or less the solution I came with with version 2, but I was struggling to decide what to do with input data that was coming when a task is executed.
It becomes even more complex when these nodes have multiple inputs (A,B,C), so each update of each input triggers a new computation that is actually not the one you expect, but that could be a valid one to compute in theory.
Just for initialization it could generate these 3 tuple of data to execute, if A' is new data, then B', then C':
A',B,C
A',B',C
A',B',C'
This can become a big bottleneck as just to load an initial .flow tree, some nodes are updated 16 times in some scenarios I have for example. I was wondering if there was some best practice that I might have missed that you might know.
Thanks for the heavy work on this project :)