enhanced_recursion() and do_event(), can they be redesigned?

[Daniel J S. <dan...@ie...>]

In attempting to modify the qt_term.cpp Qt terminal, I ran into some 
annoying problems with recursive calls, namely enhanced_recursion() and 
do_event().

First, let me summarize a few things:

1) There are a few uses of the global pointer term->.  My preference 
would be to remove those, but I understand there needs to be a way to 
get some information back to gnuplot core.  It seems to me that putting 
non-const pointers in the API is the best way to do that.  But yes, it 
is sort of the same difference.

2) By placing the Qt terminal gnuplot_qt interface in a separate thread, 
a mutex/wait is necessary for any terminal function that a) modifies one 
of these global variables via term->, b) accesses anything globally via 
pointer such as a text string.  The reason being that gnuplot core 
cannot modify things that the separate thread is just about to access or 
use anything that the separate thread has yet to modify.  This mechanism 
works fine.  In the cases where it is only objects passed into the 
thread not using pointers, the API call can return immediately because 
all those signals are queued up in the second thread and don't need any 
global access.  So, if this works, I would probably go through and first 
copy the global strings into a QString and just send that via signal to 
the terminal slot.

3) So the global variables aren't so bad, but recursive calls back into 
gnuplot core (by the code in a separate thread) are trouble because that 
is not thread safe.  If the emitter code emits a signal and then sits to 
wait for the slot to signal it has finished and wake up the emitter, a 
do_event() back into the core is going to issue another signal and wait 
a second time.  The first slot call is going to either freeze or timeout 
because potentially the gnuplot core thread is waiting for two different 
things to finish.

I've managed to move enhanced_recursion() into the emitter code (i.e., 
same thread as gnuplot core) and that works.  Inelegant, but it works. 
But I raised the white flag with the do_event() callbacks that was 
coming from mouse code.  I just commented that line out to test things 
(and get some feedback from Mojca.)

So, with that, I'll ask if there is some way of redesigning 
enhanced_recursion() and do_event().  It really doesn't fit the terminal 
concept if term code is behaving that way, i.e., calling code that 
really isn't inside its domain.

What is the role of enhanced_recursion()?

What is the role of do_event()?

Is there some way a result can be sent back via the API that indicates 
to repeat the last event?

Dan