Nagios and threads

[Daniel Eischen]

On Thu, 23 Jun 2005, Kamal R. Prasad wrote:
>
> --- Daniel Eischen <deischen at 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