2010.01.21 - it's not polite to say to a thread 'fork you!'

recently, while working new ACARM version (aka ACARM-ng¹⁾) i was investigating threads and how do they behave when fork() is called. i found a set of articles you might be interested in.

1. threads and fork - think twice before using them
2. fork() from a thread (pthreads)

if you want to keep it short, the general idea is – don't mix them (see: quotation in the title of this article)! the only exception is when calling fork() from within multi-threaded application just to call exec() in the forked process (ex. just like system() call does). there is a pitfall however, one must be aware of. when forking and spawning new process one must remember about secure file descriptor handling. in short, when calling exec() open descriptors are moved to exec'ed application.

when talking about threads there is also interesting topic on how to handle signals in threads. article thread-specific data and signal handling in multi-threaded applications covers this, though its VERY old and many things are outdated right now. the idea is to run dedicated thread just to handle incoming signals (i.e. idle 99.9999% of the time). this has another advantage – it allows to use mutexes and other synchronization mechanisms, since you know that signal will be handled in a separate thread, that will not wait forever for mutex to release.