Closed ArEnSc closed 1 year ago
The whole application is single threaded. Such functionality must be implemented on node level, you just have to write it yourself. I think nothing stops your nodes from exploiting concurrency, even starting threads and processes and have the node update itself on completion or messages - it rather comes down to the use case and what design is intuitive.
I experimented with multi-threading in Ryven itself a while ago, especially for separating execution of the GUI thread and the flow execution, but I decided it's generally not worth the struggle. It is either extremely unsafe or requires a lot of abstraction, which comes at a cost in Python.
@leon-thomm so that threading bridge code is pretty much dead code? I was trying to figure out where it was being triggered, Also could you let me know where the entry point of an exec execution would happen? When you say it's single threaded you mean the UI thread is blocked when there is a long computation ?
so that threading bridge code is pretty much dead code?
not dead code but not implementing threading right now
I was trying to figure out where it was being triggered
In a few places, it's a ryvencore-qt thing - primarily in FlowCommands.py
(see FlowUndoCommand
).
Also could you let me know where the entry point of an exec execution would happen?
That's happening in ryvencore. The current version of Ryven runs on ryvencore v0.3. An update doesn't happen without a reason, either direct interaction from the user (using the node), or something else that the user or node developer set up. In early versions, update messages were always passed from node output to node input directly (quite literally, the node output object calling the connection object, which then calls the node input object, which then triggers its node's update
method). This was gradually replaced by a central FlowExecutor
class, see here and here. This was standardized in the WIP ryvencore v0.4 which will power the next Ryven release, so everything will go through the FlowExecutor.
When you say it's single threaded you mean the UI thread is blocked when there is a long computation ?
yes, i.e. threading and concurrency should be built into the nodes themselves if it is needed.
@leon-thomm thank you for your answers! it means a lot I have gotten this to work for something I am working on just trying to figure out more of the details
@leon-thomm Hey quick question is there a way to wait the thread that operates the node execution then have it wake up when an async task is done? I have async nodes and the only way I can sorta fix this is if I add a delay node in between thanks!