From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 23 13:58:45 2005 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5FBBE16A41C for ; Thu, 23 Jun 2005 13:58:45 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D51943D4C for ; Thu, 23 Jun 2005 13:58:42 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.13.4/8.13.4/NETPLEX) with ESMTP id j5NDwYlu017697; Thu, 23 Jun 2005 09:58:34 -0400 (EDT) Date: Thu, 23 Jun 2005 09:58:34 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: kamalp@acm.org In-Reply-To: <20050623092545.81995.qmail@web52705.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: Charles Sprickman , hackers@freebsd.org, Peter Edwards Subject: Re: Nagios and threads X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2005 13:58:45 -0000 On Thu, 23 Jun 2005, Kamal R. Prasad wrote: > > --- Daniel Eischen 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