Re: Qt on Mac (was: Getting ready to put out a 4.6 release candidate)

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

On 01/05/2012 11:01 AM, Ethan A Merritt wrote:
>> On 01/05/2012 01:35 AM, Daniel J Sebald wrote:
>>
>> Be that as it may, it might pay to step back a bit and consider just
>> what the QApplication is doing.
>>
>> But first, let me ask whether
>>
>>                  // Start
>>                  application.exec();
>>                  exit(0);
>>
>> should be _exit(0) instead of exit(0).
>
> Good point.  But that wouldn't help if there is an exit() call
> inside application.exec() somewhere, e.g. from an error.

If there's an exit() inside QtCore I can't tell (e.g., user closes all 
terminals using the mouse), but I would hope that is done gracefully in 
Qt.  There is a qt_atexit() routine, so I would guess that is the last 
thing called when QApplication is complete.  But that still doesn't 
answer if Qt exits directly or always comes back to the application.exec().

There is an exit() inside QtGnuplotEventHandler::readEvent() that you 
added to deal with any zombie processes.  The other way to get rid of 
zombies is to use the "wait()" inside the parent process after sending a 
drawing command to the Qt terminal.  (In that case, maybe exit should be 
replaced by a change in signal to indicate to the parent that something 
went wrong.)  If zombie processes are destroyed along with the parent, 
having a zombie process around isn't necessarily bad, unless it is a CPU 
hogging infinite loop.


>> J�r�me, do you think it would make sense to set up initialization of the
>> Qt terminal similar to the gplt_x11 terminal for better organization and
>> enable function under OS X at the same time?
>
> Wouldn't the IPC channel have to be revised as well?
> See the comments at the top of qt_flushOutBuffer() in qt_term.cpp

I see the comment, but I'm not completely understanding.  I did read in 
the Qt documentation somewhere that this flush was necessary so that 
there aren't duplicate input data of some sort.

Dan