Date: Tue, 21 Jun 2005 15:50:29 +0100 From: Peter Edwards <peadar.edwards@gmail.com> To: Charles Sprickman <spork@fasttrackmonkey.com> Cc: hackers@freebsd.org Subject: Re: Nagios and threads Message-ID: <34cb7c840506210750f7458cf@mail.gmail.com> In-Reply-To: <Pine.OSX.4.61.0506201654400.374@gee5.nat.fasttrackmonkey.com> References: <Pine.OSX.4.61.0506201654400.374@gee5.nat.fasttrackmonkey.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 6/20/05, Charles Sprickman <spork@fasttrackmonkey.com> wrote: > Hello, >=20 > Just curious if there's any regulars here who would like to help Ethan > out: >=20 [snip] >=20 > ... It happens when the main thread forks to execute an active > check. On the second fork to create the grandchild, the grandchild is > created by fork, but never returns from liblthread's fork wrapper, becaus= e > it's stuck in __pthread_acquire(). Maybe some FreeBSD users can help out > with this problem." >=20 IIRC, doing any significant work in a forked child of a multithreaded process is somewhat ill defined. From SusV3's description of "fork()" > ... Consequently, to avoid errors, the child process may only execute=20 > async-signal-safe operations until such time as one of the exec > functions is called. (This behaviour would extend to a grandchild.) A comment in libpthread/thr_kern.c refers to this, so I think there's at least some assumptions that the child won't be doing much before execing or exiting. (But Im sure one of the implementors will pipe up if I'm wrong :-))
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?34cb7c840506210750f7458cf>