[Qt-interest] return to command line but the GUI is still alive

[william.crocker at analog.com]

>> I think this one deserves an explanation as well.
>> (I know the reason because I got caught by it several years ago,
>>  but I'm sure other Qt users could benefit.)
>
> The problem is the same as the other explanation: fork() marks all memory 
> pages as Copy-On-Write, but all other resources are shared.
>


This is what I encountered.

Qt assumes a multi-threaded app and so locks certain resources.
When fork() is called, only the current thread is forked and
all other threads are frozen (in the child process.)

The problem is that one of the frozen threads may be holding a lock.
If one starts using Qt from the forked context and needs that lock then the
thread will freeze waiting for the lock to be released, which will never
happen.

I realize that this is not Qt's fault.

What bothered me was the deep under the implementation of seemingly simple
classes like QFile and QFileInfo, Qt was using a Mutex to lock some shared
resource (or at least it was two years ago.) Now, several hundred lines 
of code
later, I have my own fork-safe versions of a dozen Qt classes which I needed
to use in a forked context.)

What bothers me now is that this issue is still not mentioned in the
Qt documentation (as determined by a grep for the word: "fork".)

Bill C.
Respectful Qt user.