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

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

On 02/08/2014 12:28 PM, sfeam wrote:
> 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.

Ah, you're correct.  I remember something like that now, but it is for 
Qt.  Qt only allows graphics in the main thread.  Other threads not, 
hence there needs to be a bit of communication between threads.  If that 
restriction goes back to some OS's restrictions, I'm not sure.  Let's 
avoid such a rework because it doesn't fit the gnuplot term paradigm. 
I've seen a lot of talk about the fork issue and OSX, so I assumed there 
was more to it, but apparently it's not such an issue--no more than 
other flavors of Unix.


> 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.

Yes, Qt probably does such a thing behind the scenes.  I've looked at 
the Qt source.  The file is called qprocess_unix.cpp, and best I can tell is

* If the OS is QNX, then

   startDetached -> doSpawn

   and ::doSpawn disallows multithreaded programs from forking
   (I assume somewhere down the road Qnix spawn is the equivalent
   of fork/exec)

* If the OS is Unix, then

   startDetached sets up a safe pipe to catch the start of the child
   startDetached then does fork
   startDetached then calls a memset (I don't think that requires OS)
   startDetached then does some signal setup and closes the started pipes
   startDetached then does a second fork (I'm not quite sure why)
   startDetached then does all kinds of manipulations of QStrings,
                 argv[] for the process, etc.  But it does look to
                 me that all these variables are on the stack.
   startDetached then calls qt_safe_execv
   The only OSX-specific code within all of startDetached is this:
   #ifdef Q_OS_MAC
                   argv[i + 1] = 
::strdup(arguments.at(i).toUtf8().constData());
   #else
                   argv[i + 1] = 
::strdup(arguments.at(i).toLocal8Bit().constData());
   #endif
   so nothing special there.

* The qt_safe_exec## set of functions are inline calls of the form

       EINTR_LOOP(ret, ::execve(filename, argv, envp));

   and EINTR_LOOP is nothing special either, just loops until the
   process exits without having been interrupted

So, with all that, I'm surprised that Qt does so much manipulation of 
data in between the fork and the exec## family of functions and 
presumably OSX doesn't complain.  gnuplot wasn't doing much different 
with "QString filename" on the stack, so I'm guessing the 
getenv("GNUPLOT_DRIVER_DIR") between the fork and exec was what OSX 
complained about in old versions of the code.

OK, great.  Now which version of gnuplot will have the portable 
QProcess::startDetached so that I may tell folks who want to know?  I 
see from the ChangeLog this just made it into the source code with the 
past three weeks.

Dan