I think all calls from the GUI to the interpreter are now done in a
We now consistently use the following pattern to call the interpreter
from the GUI:
([CAPTURES] (interpreter& interp)
// Code to run in the interpreter thread.
Note that the use of lambda expressions allows us to write functions in
the GUI sources that call code from the interpreter (and that will be
executed in the interpreter thread) but that may also emit Qt signals
directly in order to call back to the GUI thread for further action.
Doing this job without lambda expressions would be somewhat more
difficult and less clear.
The most complicated case I think I came across is the code in
file-editor-tab.cc to save a file, because it checks whether the file
that is being saved is currently being executed in the debugger, and if
so, displays a confirmation dialog (running in the GUI thread), then
jumps back to the interpreter thread to clear the function and the back
to the GUI thread to save the file.
After making these changes, I attempted to audit the code to determine
that I had actually removed all unsafe calls across threads. To do
that, I commented out all the code inside the lambda expressions passed
to the interpreter_event signals and all include statements that include
header files from the interpreter, then compiled Octave and examined
error messages about symbols that were used without declarations. By
doing that, I found the places where we still call some interpreter
functions directly from the GUI, but as far as I can tell, those
functions are thread safe.
I'm not sure of any better way to make this assessment about thread
safety. If anyone has ideas, please share!
In the future, we should be careful to follow the patterns now used in
the interpreter_event signals and to avoid calling any interpreter
functions directly from the GUI unless they are known to be thread safe.
I'll post a separate message about the current state of the
event_manager class (formerly known as octave_link).