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

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

On 01/04/2012 11:49 PM, Daniel J Sebald wrote:
> On 01/04/2012 11:20 PM, sfeam (Ethan Merritt) wrote:
>> On Wednesday, 04 January 2012, Daniel J Sebald wrote:
> [snip]
>> Dan:
>>
>> I could be wrong, but I don't think that  "application.exec()" is actually
>> an exec() call in the normal linux sense.   See for example
>>     http://stackoverflow.com/questions/3880693/qapplication-exec-creates-new-thread-process
>>
>> In this case it just means "start looping over the draw commands until I
>> tell you to stop".   So your idea would be spot on if this were a real exec(),
>> but I'm afraid it's not going to help in this case.   But hey, I could be wrong.
>> It's simple enough to give it a try.
>
> Oh, that's a problem then.  The the code following the fork probably
> needs to be written as a separate program and run via exec().  That's
> considerable more work.
>
> Sorry, I can't find application.exec(), but if all it does is reads
> commands until done, then after that exit(0), why does this process need
> to be forked?  (Maybe you don't know the reason.)

Answering my own question as best I can.  If I'm understanding 
correctly, Qt provides a mechanism for creating threads:

http://developer.qt.nokia.com/doc/qt-4.8/qthread.html

This is supposedly platform independent, which would suggest gnuplot's 
qt_init() shouldn't be using fork(), which is a platform dependent 
routine.  Maybe QThread is the way to go, and it takes care of all the 
fork/exec issues at its core.

Dan