Date: Wed, 22 Jun 2005 10:25:19 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: Norbert Koch <NKoch@demig.de> Cc: Charles Sprickman <spork@fasttrackmonkey.com>, hackers@freebsd.org, kamalp@acm.org, Peter Edwards <peadar.edwards@gmail.com> Subject: RE: Nagios and threads Message-ID: <Pine.GSO.4.43.0506221022440.22792-100000@sea.ntplx.net> In-Reply-To: <000801c5772a$23dac9c0$4801a8c0@ws-ew-3.W2KDEMIG>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 22 Jun 2005, Norbert Koch wrote: > > [snip] > > > at least some assumptions that the child won't be > > > doing much before > > > execing or exiting. (But Im sure one of the > > > > The child process should be able to call any system > > calls it likes -without assuming that pthreads from > > the parent process have been copied over to the child > > process. I spose most implementations support that. > > > > regards > > -kamal > > >From "Programming with POSIX Threads" [David R. Butenhof]: > > p.197-198: > ... Avoid using fork in a threaded program (if you can) > unless you intend to exec a new program immediately > ... Pthreads does not "terminate" the other threads > in a forked process. ... They simple cease to exist. > ... The state of mutexes is not affected by a fork. If > it was locked in the parent it is locked in the child! Yes, and realize that both libc and libpthread are consumers themselves of mutexes (and CVs). Also, some system calls are wrapped by libpthread to provide cancellation points. Unless you exec after the fork, you may be relying on inconsistent mutex state. -- DE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.43.0506221022440.22792-100000>