Anything in particular I need to be aware of in an application that is multi-threaded, but also does regular forks? I've studied some of the stuff talked about in the man-page for pthread_atfork(), and none of it applies to my situation. I don't think I have a specific problem with fork(), I'm just trying to eliminate that option. /Per Jessen, Zürich
On Thu, 9 Mar 2006, Per Jessen wrote:
Anything in particular I need to be aware of in an application that is multi-threaded, but also does regular forks? I've studied some of the stuff talked about in the man-page for pthread_atfork(), and none of it applies to my situation. I don't think I have a specific problem with fork(), I'm just trying to eliminate that option.
I contribute to an open-source application that uses both fork's and pthreads. As long as I keep all of the GUI operations mostly limited to one thread it works fine, although I'm doing some popup dialogs from other threads without incident. X11 or Motif seem to have problems with more than one thread talking to it at once. Ours is a graphical/mapping application so we're doing a lot of X11 calls. -- Curt, WE7U. APRS Client Comparisons: http://www.eskimo.com/~archer "Lotto: A tax on people who are bad at math." -- unknown "Windows: Microsoft's tax on computer illiterates." -- WE7U "The world DOES revolve around me: I picked the coordinate system!"
On Thursday 09 March 2006 10:43 am, Per Jessen wrote:
Anything in particular I need to be aware of in an application that is multi-threaded, but also does regular forks? I've studied some of the stuff talked about in the man-page for pthread_atfork(), and none of it applies to my situation. I don't think I have a specific problem with fork(), I'm just trying to eliminate that option. I suggest you get Dave Butenhof's book, "Programming with POSIX Threads". This is an excellent book and Dave certainly knows his stuff since he was one of the primary threads developers for both VMS and Tru64_Unix.
If you can avoid using fork(2) in a threaded application, then do so. If you need to use fork(2), just try to be aware that in the child, the only thread that will exist in the child process is the thread that actually performed the fork(2). But, the data states and mutexes should be in the same state. -- Jerry Feldman <gaf@blu.org> Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
Jerry Feldman wrote:
I suggest you get Dave Butenhof's book, "Programming with POSIX Threads". This is an excellent book and Dave certainly knows his stuff since he was one of the primary threads developers for both VMS and Tru64_Unix.
Thanks, I'll check that out. I've got plenty of experience with multi-threaded programming, mutexes, spinlocking, atomic exchanges and all that jazz, except specifically in the POSIX model.
If you can avoid using fork(2) in a threaded application, then do so.
I would if I could.
If you need to use fork(2), just try to be aware that in the child, the only thread that will exist in the child process is the thread that actually performed the fork(2).
Yep, I understand that too. I execve() very quickly anyway - I only the usual stuff of getpid(), couple of dup2()s and such. Does anyone have a list of the async-signal-safe library functions that can be called safely between the fork() and the exec()? The only list I've found on the 'net seems to come from a Solaris man page. /Per Jessen, Zürich
participants (3)
-
Curt, WE7U -
Jerry Feldman -
Per Jessen