hal
hal copied to clipboard
emsec
Endless Python loops hang the GUI [fixed in new HAL version 4.0]
Describe the bug Writing an endless loop (by accident) will block the HAL user interface. There is currently no way to cancel a running script or console command besides killing HAL.
To Reproduce
- Write a
while 1: passloop in the Python editor - Click run
Expected behavior The GUI should remain responsive and the run button should turn into a stop button to allow manual termination of the script.
The Python script seems to run on the GUI thread, which in turn blocks the Qt event pipeline and makes the GUI unresponsive. Instead, execution should take place in a separate worker thread.
This currently also means one can't print progress messages to the HAL Python console while a script is running.
The reason the python context is run in the main thread is pretty simple: Netlist access is currently not threadsafe. Running the python context in another thread could consequently result in data corruption / access violations / etc. The same goes for plugins and anything else that might access the netlist. Cannot be threaded currently. I've actually raised this issue multiple times already, but so far nobody else seems to be particularly bothered by it.
@RenWal I see your point. We should make the data model thread and probably multiprocess safe. This would also allow us to run an analysis on a multi-node structure to increase performance. We should think about doing that in the near future.
Thread safety will surely have negative performance impacts, which can be partially circumvented with shared_mutex. The problem I see is not introducing thread safety, but testing it...
How to make sure that all race conditions are gone, that there are no deadlocks, etc.
