Re: Event queue(s) between the GUI and the interpreter

[Daniel J Sebald]

On 05/07/2014 03:07 PM, Jordi Gutiérrez Hermoso wrote:
> While patching bug #42307 to use Fsource directly without attempting
> to invoke the interpreter on a filename (thus getting rid of the
> problem of even considering what characters are in the filename), I
> came to the conclusion that this could be easily done by directly
> passing Fsource with the right parameters to the octave_link class.

Hi Jordi,

I've not looked closely at the Fsource patch, but the issue you are 
raising is one that I think can be a main focus of OctConf '14.  That 
is, we should come up with a generic and flexible paradigm for 
communication and interaction between the GUI and Octave core (worker 
process in the Qt paradigm) that we agree upon.  Michael's recent posts 
regarding Script Callbacks (something completely different from C-code 
callbacks internal to the source) have cleared up some issues with data 
exchange suggesting that there is a bit of convergence on what 
developers are attempting to do and the work that Torsten has done.

If by directly you mean for the GUI to start calling code within Octave 
core, my feeling is that's not a good way to go.

"Part of the idea of tying the GUI tightly with Octave is so that we 
could directly use Octave's general C++ API from the GUI."

I don't necessarily agree with that.  The goal that seems to be emerging 
is a flexible and adaptable GUI for which features can be added.  We've 
gone with Qt.  Qt has a paradigm and provides all the typical tools of 
Mutex's and so on, including multi-threaded, that works with that 
paradigm.  The GUI is in one thread, the worker process is in another 
thread.  Calling C++ API directly doesn't have any bearing on that goal.

The problem is the multi-threaded nature of the GUI.  If someone were to 
write something single-threaded with a less feature-rich GUI development 
tool, then calling API is fine.  In the multi-threaded environment, 
direct calls to code start to restrict the flow and probably limit what 
can be done.


> However, I'm now confused. It looks like there are two queues, one in
> the interpreter called gui_event_queue and another in the GUI called
> _cmd_processing, each with its own mutex and/or semaphore. It looks
> like the gui_event_queue gets fed with functions from the GUI (i.e.
> defined in libgui), and that _cmd_queue gets fed with actual commands
> stored as QStrings that get called from
> main_window::execute_command_callback (btw, exactly which line in this
> last function is responsible for actually executing the command?
> command_editor::replace_line?)

My feeling is that there needs to be two queues

1) "Foreground Queue"  These are things for which there is output 
appearing in the command-line window.

2) "Background Queue"  These are things the GUI is doing that can't be 
seen in the command-line window.  E.g., querying for variable information.

(We could combine the two with some "mode" as part of the queued 
command, but I think from a developers standpoint it is easier to deal 
with two types of queues and not worry about some mode setting.)  We've 
had the "Foreground Queue" from the start of the GUI.  The background 
queue is something I've tested and verified that data can be sent back 
to the GUI in octave_value format _as a pointer_ across threads.

If there are already two queues, I'm thinking one of them can be shaped 
into the background queue.


> So where exactly would I do something like call Fsource directly?
> Should I create another queue-mutex-semaphore triplet in the GUI for
> DEFUNs and feed gui_event_queue with function calls to a function like
> main_window::execute_defun_callback?

I'd say, no third queue.


> This seems a bit convoluted, but par for the course for Octave code.
> :-)

That's what I'm trying to avoid and why I suggest working this out in 
discussions at OctConf.  By having a setup as described above that is 
flexible enough to do whatever is wanted it avoids individual developers 
dreaming up clever ways to inject their code into the program flow.

Dan