You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The goal is to never freeze the main canvas GUI thread/process. When a widget is doing something, its window can freeze, but other widgets and the canvas should still be interactable. The widget's NodeItem on canvas should display an indefinite loading animation.
Note: It's still great to multithread things within widget, this'll make the widget's window not freeze while the task is running.
@PrimozGodec noted that threads cannot be forcefully stopped, so they're not appropriate for this. With threads, the solution would have to check if it was signalled to stop every so often, which is not viable for large-scale concurrency.
A multi-process solution must be implemented. To a widget process, the outside world must be immutable. Communicating with the main process, it receives some input signal data and sends some output signal data.
The canvas end must wait for the widget's processing to finish without freezing up. So there should be a thread waiting for widgets to finish, and/or receiving outputs should be integrated into the Qt event loop?
The text was updated successfully, but these errors were encountered:
Also, perhaps this should be implemented with multi-core support in mind for the future? (as I understand, Orange currently supports only single-core computation)
I suppose that's a discussion for another time.
Today @ajdapretnar, @lanzagar, @PrimozGodec and I talked about making all Orange widgets run concurrently.
The goal is to never freeze the main canvas GUI thread/process. When a widget is doing something, its window can freeze, but other widgets and the canvas should still be interactable. The widget's
NodeItem
on canvas should display an indefinite loading animation.Note: It's still great to multithread things within widget, this'll make the widget's window not freeze while the task is running.
@PrimozGodec noted that threads cannot be forcefully stopped, so they're not appropriate for this. With threads, the solution would have to check if it was signalled to stop every so often, which is not viable for large-scale concurrency.
A multi-process solution must be implemented. To a widget process, the outside world must be immutable. Communicating with the main process, it receives some input signal data and sends some output signal data.
The canvas end must wait for the widget's processing to finish without freezing up. So there should be a thread waiting for widgets to finish, and/or receiving outputs should be integrated into the Qt event loop?
The text was updated successfully, but these errors were encountered: