Simultaneous qt and wxt terms (was Re: Proposal: Saving graphs from Qt and wxt terminals)

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

On 10/25/2014 12:54 AM, sfeam wrote:
> On Saturday, 25 October 2014 12:18:45 AM Daniel J Sebald wrote:
>
>>
>
>>  I notice that gnuplot doesn't allow wxt and Qt in the same session.
>
>>  What is the issue there? I see this:
>
>>
>
>>  /* The qt and wxt terminals cannot be used in the same session. */
>
>>  /* Whichever one is used first to plot, this locks out the other. */
>
>>  void *term_interlock = NULL;
>
> The wxt and qt libraries do not play nicely with each other.
>
> They trample on each other's memory allocation schemes.
>
> Or at least they did back when qt was first added to gnuplot.
>
> Rather than having the program die in strange ways from the
>
> memory conflict, it seemed better to only allow one or the
>
> other at a time.
>
> You could try removing the interlock test to see if the memory
>
> conflict is still there. I haven't gone back to check for a
>
> long time.

I removed the interlock test and it creates quite a mess with invalid 
events, seg faults in bad library calls, to scratch the surface.

Investigating a bit, I think the problem lies in the fact wxt terminal 
is not in its own process.  I notice in the PID list that there is 
gnuplot_qt and when resizing the Qt window, that process CPU consumption 
ramps up.  Now, when resizing the wxWidgets plot window it is the other 
"gnuplot" process for which CPU consumption ramps up.

Running two separate gnuplot processes, one running Qt term and the 
other running wxt term seems to have no problems.  This really isn't a 
surprise, as it just confirms that Qt and wxt can exist at the same time 
in the desktop space.

If I recall correctly, fork() is used to create a separate process for 
the Qt outboard plotter--thus Qt can do graphics in that new process 
with default main thread.  But under the scenario of both qt and wxt 
terminals active the problem is that there are two graphics entities in 
a main thread, which is probably bad.  For example:

launch gnuplot     -> PID_gnuplot created
plot into wxt term -> instantiate underlying graphics in PID_gnuplot
set term qt        -> fork PID_gnuplot process for which wxt graphics
                    -> is already active to create PID_gnuplot_qt
plot into qt term  -> instantiate underlying graphics for PID_gnuplot_qt

At that point PID_gnuplot_qt has two underlying graphics "kernels" (for 
lack of better understanding) in its main thread probably creating havoc 
at a real low level.

I think that wxt needs to be in its own process, i.e., an outboard 
plotter.  What about these other terminals that remain persistent?

"
  Many gnuplot terminals (aqua, pm, qt, x11, windows, wxt, ...)
  open separate display windows on the screen into which plots
  are drawn.  The `persist` option tells gnuplot to leave these
  windows open when the main program exits.
"

x11 is also outboard, so that should work fine with qt terminal, and I 
just confirmed it does.  But then again, it could simply be that x11 is 
very low level (doesn't use the file dialogs and whatever else).  Is 
there anyone who can run both aqua followed by qt, or does that have a 
similar clash of system resources?

I see that when exiting, that's when wxt_atexit() forks:

	if (openwindows > 0)
		pid = fork();
	else
		pid = -1;

	/* the parent just exits, the child keeps going */
	if (!pid) {

That works, but at the same time it's not really exiting the process, 
just giving the command line back to the terminal window.  The exact 
same process exists as a duplication.

Dan