Re: [ gnuplot-Bugs-3468950 ] Qt, moc and uic not found on Mac OS X

[Ethan A M. <eam...@gm...>]

On Tuesday, 10 January 2012, Tait wrote:
> > $ ./gnuplot             # terminal defaults to qt
> > gnuplot> plot x         # so far, so good
> > 
> > [in another terminal window]
> > $ ps -efT | grep gnuplot           # both ./gnuplot and gnuplot_qt visible
> > $ kill -9 <pid of ./gnuplot>
> > $ ps -efT | grep gnuplot           # gnuplot_qt is visible, ./gnuplot is gone
> > ...
> > I think the problem is that if the parent process dies hard,
> > either from an unintentional segfault or from receiving a KILL signal,
> > then any atexit() processing that would have sent a signal to the 
> > child doesn't happen.
> > ... 
> 
> The definition of a -9 kill is that the killed process CANNOT
> catch/handle/ignore the signal, receives no warning, and has no
> opportunity to clean up. 

Exactly. That was the point of the test.
I wanted to reproduce a condition where the parent process did not
send a signal to the child. 

> Maybe you were thinking of a kill -1 (the
> default), which sends a sighup? A process would normally catch this and
> do the usual clean up before dying.

For what it's worth, I see exactly the same behaviour if I send
kill -HUP.

> The Qt discussion is way beyond my understanding, but the mechanism
> I've seen before for children to die gracefully when a parent dies is
> to keep a pipe open to the parent process, and then react to the
> sigpipe the child would receive if the parent died.

The issue is complicated somewhat by gnuplot's "-persist" option.
If "persist" is set, then the plot window is supposed to remain on
display even though the parent process has exited.  Of course you 
are also supposed to be able to close/kill the display itself when
you are done with it.  I squashed a bug in the earlier CVS version
of the qt driver that left you unable to get rid of the child window
if it had already been closed at the time "persist" mode was enabled.
The equivalent problem may have recurred in the fork/exec variant.

However, I was _not_ using the -persist option in my tests.
But it is possible, I suppose, that the code is incorrectly executing 
that path anyhow.  

Jérôme:
Is it possible that the setting from
   setQuitOnLastWindowClosed(false)
is persistent across Qt sessions?  That is, maybe that setting is
handled by the QSettings mechanism that you already described for
the background color?

	Ethan


-- 
Tradition is not the worship of ashes, but the preservation of fire.
  - Gustav Mahler