From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 22 14:31:46 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 EF8A916A427 for ; Wed, 22 Jun 2005 14:31: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 B2BBC43D1D for ; Wed, 22 Jun 2005 14:31:45 +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 j5MEVfWS006455; Wed, 22 Jun 2005 10:31:41 -0400 (EDT) Date: Wed, 22 Jun 2005 10:31:41 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Peter Edwards In-Reply-To: <34cb7c8405062207246b582eaf@mail.gmail.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, kamalp@acm.org 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: Wed, 22 Jun 2005 14:31:46 -0000 On Wed, 22 Jun 2005, Peter Edwards wrote: > On 6/22/05, Kamal R. Prasad wrote: > > > > 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. > > > > 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. We do protect the malloc lock across a fork(), but that's it. -- DE