Date: Wed, 22 Jun 2005 15:24:07 +0100 From: Peter Edwards <peadar.edwards@gmail.com> To: kamalp@acm.org Cc: Charles Sprickman <spork@fasttrackmonkey.com>, hackers@freebsd.org Subject: Re: Nagios and threads Message-ID: <34cb7c8405062207246b582eaf@mail.gmail.com> In-Reply-To: <20050622124007.75760.qmail@web52702.mail.yahoo.com> References: <34cb7c840506210750f7458cf@mail.gmail.com> <20050622124007.75760.qmail@web52702.mail.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 6/22/05, Kamal R. Prasad <kamalpr@yahoo.com> wrote: > [snip] > > at least some assumptions that the child won't be > > doing much before > > execing or exiting. (But Im sure one of the >=20 > 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. >=20 There's more to it than system calls, though (most (all?) of which will be async-signal-safe anyway). Simple example: any lock that the libc implementation needs to provide its functionality may be arbitrarily locked by some other thread: eg, one thread calls malloc() as another calls fork(): the original thread ceases to exist in the child while holding a lock in malloc, leaving malloc() unusable in the process. It may be that FreeBSD is less tolerant of this than other OSes, and the failure may occur more frequently, but I'm not sure that there's anything wrong with it per se.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?34cb7c8405062207246b582eaf>