====== 2010.01.21 - it's not polite to say to a thread 'fork you!' ======
recently, while working new [[http://www.acarm.wcss.wroc.pl|ACARM]] version (aka ACARM-ng((no home page yet))) i was investigating threads and how do they behave when //fork()// is called. i found a set of articles you might be interested in.
  - [[http://www.linuxprogrammingblog.com/threads-and-fork-think-twice-before-using-them|threads and fork - think twice before using them]]
  - [[http://unix.derkeiler.com/Newsgroups/comp.unix.programmer/2003-09/0672.html|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 [[http://udrepper.livejournal.com/20407.html|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 
[[http://www.linuxjournal.com/article/2121|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.