Re: Reworked qt terminal is much faster – and fails to work on Mac

[sfeam <sf...@us...>]

On Saturday, 08 February 2014 12:57:00 AM Daniel J Sebald wrote:
> 
> Others have asked for gnuplot to not use fork() for OSX.  I think it is 
> ultimately up to someone with an OSX machine to do this.  If we could 
> figure out how to do this with threads instead of fork, maybe that is a 
> solution.  

I think you have that backwards.
As I understand it, OSX does not like running the graphics display
loop in a separate thread but is OK with running it in a separate process.
So fork=good, separate thread=bad.

As you might expect, the source code for QProcess::startDetached()
(at least in the linux version) basically consists of fork+exec.
So the change to calling the Qt library routine rather than doing the
fork+exec in-line should not have made any functional difference.
Of course if the OSX Qt implementation does something wacky
in QProcess::startDetached()  that's another thing altogether.

Mojca: - Do you have GNUPLOT_DRIVER_DIR set to the current
build directory?  I could imagine that if the new executable forks
a copy of an old gnuplot_qt that strange things might happen.

If you run with the following trivial patch, does the reported 
process ID make sense?

--- gnuplot/src/qtterminal/qt_term.cpp  2014-01-26 13:57:10.687171903 -0800
+++ gnuplot-cvs/src/qtterminal/qt_term.cpp      2014-02-08 10:25:19.819905362 -0800
@@ -211,9 +211,10 @@ void execGnuplotQt()
 
        qint64 pid;
        qt->gnuplot_qtStarted = QProcess::startDetached(filename, QStringList(), QString(), &pid);
-       if (qt->gnuplot_qtStarted)
+       if (qt->gnuplot_qtStarted) {
                qt->localServerName = "qtgnuplot" + QString::number(pid);
-       else
+               qDebug() << "started detached process " << qt->localServerName;
+       } else
                qDebug() << "Could not start gnuplot_qt with path" << filename;
 }

	Ethan