6

When I fork() in a Qt application, what parts of Qt behave sane? Does Qt support this?

Obviously, e.g. the GUI on MacOSX will not work because Cocoa itself does not support forked processes.

But there are many other parts, e.g. the list of threads, etc.

QCoreApplication::applicationPid() seems to return the wrong value. (According to here.)

Or to put the question a bit different: I must fork() in my app and there are certain parts which might access Qt in the child process. Where do I need to take extra care, despite all the Qt GUI stuff?

Community
  • 1
  • 1
Albert
  • 65,406
  • 61
  • 242
  • 386
  • Anecdote: I used `fork()` and then `gdb attach` to get a backtrace of my qt application on a sigsegv => the X server froze and you had to restart the computer. – BeniBela Feb 12 '14 at 12:30
  • Read [man fork](http://linux.die.net/man/2/fork). BTW Why would anyone fork, and not do execve in the child? What are you trying to do? – BЈовић Feb 12 '14 at 13:02
  • @BЈовић: There are certain things you can do much easier via a `fork`. But that is not really the scope of the question here, there are many flamewars whether forks should be used or not. – Albert Feb 12 '14 at 13:28
  • Do you have a link to text explaining at least one? – BЈовић Feb 12 '14 at 13:34
  • @BЈовић: [Here](http://stackoverflow.com/questions/9949940/usefulness-of-fork-besides-executing-foreign-programs), [here](http://stackoverflow.com/questions/4093185/whats-the-difference-between-epoll-poll-threadpool/) or [here](http://stackoverflow.com/questions/807506/threads-vs-processes-in-linux). Basically always when you have to share a lot of data between different processes, a fork makes sense. But it also simplifies the code a lot. – Albert Feb 12 '14 at 14:53

2 Answers2

4

TL;DR "What can I use from Qt in the fork?" "Anything, as long as you prove to yourself, via code audit, that there are no bugs there related to forking".

None of this is tested for, so nobody knows if anything related to forking used to work, and got broken, and whether it still works.

Qt has a continuous integration system and it is tested on multiple platforms as a prerequisite for staging the changes into a future release. This includes testing for performance regressions in the key areas. IOW, it's not a joke of a test suite, it's for real. The fact that forking is not addressed in the test suite should be a strong signal to you that you're on your own here.

So, you need to take care everywhere, and you need to audit the entirety of Qt code that you call. Sorry, that's the only reasonable answer.

Kuba hasn't forgotten Monica
  • 95,931
  • 16
  • 151
  • 313
  • From comments [here](http://stackoverflow.com/a/808955/476681) : "@Qwertie forking is not that cool, it breaks lots of libraries in subtle ways (if you use them in the parent process). It creates unexpected behaviour which confuses even experienced programmers. – MarkR"... so, this is only sensible answer. – BЈовић Feb 12 '14 at 15:31
1

On MeeGo there was a daemon applauncherd which boosted start up time of Qt applications by forking it when it was needed. So in general it is possible, but as you noticed QCoreApplication::applicationPid() returns wrong value. I far as I known MeeGo used a slightly modified version of Qt. It is open source project so you can inspect code how they fixed the problem.

Another thing when you are using fork then you loost portability, so once you have used fork you can use fork related API and don't use QCoreApplication::applicationPid() but use directly getpid function.

Marek R
  • 32,568
  • 6
  • 55
  • 140
  • 1
    The question is more: What can I use from Qt in the fork? – Albert Feb 12 '14 at 13:29
  • And MeeGo project proves that almost anything. `applauncherd` was so smart that it was able to fork process with preinitialized window (not visible yet). There was a security issue related to fork and dbus. – Marek R Feb 12 '14 at 17:21
  • Well, but GUI stuff is heavily platform dependent. I'm quite sure that the same would not be possible on MacOSX/Cocoa. Also, the question is then, how much of Qt can be used before the `fork()`. Because if I never create any other threads, that probably won't be an issue -- but it might confuse Qt if there were other threads before the `fork()`. – Albert Feb 12 '14 at 19:41