Date: Thu, 23 Jun 2005 09:58:34 -0400 (EDT) From: Daniel Eischen <deischen@freebsd.org> To: kamalp@acm.org Cc: Charles Sprickman <spork@fasttrackmonkey.com>, hackers@freebsd.org, Peter Edwards <peadar.edwards@gmail.com> Subject: Re: Nagios and threads Message-ID: <Pine.GSO.4.43.0506230954220.27981-100000@sea.ntplx.net> In-Reply-To: <20050623092545.81995.qmail@web52705.mail.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 23 Jun 2005, Kamal R. Prasad wrote: > > --- Daniel Eischen <deischen@freebsd.org> wrote: > > > (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. > > > How about doing some cleanup in a pthread_atfork() > routine? It can be done by the user or a libc/X stub > that gets called implicitly. That may or may not be done in the future, but don't rely on it. In fact, it'd be nice to make it fail spectacularly :-) > > We do protect the malloc lock across a fork(), but > > that's it. > > > Isn't it possible that an application may genuinely > want to fork() out a child and not exec() another > process.? I don't care what it does, as long as it's allowed by POSIX. If you're going to fork() and not exec(), you might as well use pthread_create() instead of fork(). -- DE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.43.0506230954220.27981-100000>