From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 23 09:25:47 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 0DE1016A41C for ; Thu, 23 Jun 2005 09:25:47 +0000 (GMT) (envelope-from kamalpr@yahoo.com) Received: from web52705.mail.yahoo.com (web52705.mail.yahoo.com [206.190.39.156]) by mx1.FreeBSD.org (Postfix) with SMTP id 9E4D843D4C for ; Thu, 23 Jun 2005 09:25:46 +0000 (GMT) (envelope-from kamalpr@yahoo.com) Received: (qmail 81997 invoked by uid 60001); 23 Jun 2005 09:25:45 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=f3Tf/9N5Ng9A4VQZPMvqbnOp1zdfWJStqWlQ36QqsMAMzl/bAjOQvxyxnoXnDF3pPS2r9E5zPbOgv1tl8KVa++2p7Kt7wvznVj/TGiOwrQbjqf7qg7fsPvi9hB7OXHJHFHpgIkvUHB0fqoaQ3rKWmzsh/QhKq6Hemm3T7OTfhU0= ; Message-ID: <20050623092545.81995.qmail@web52705.mail.yahoo.com> Received: from [210.18.86.20] by web52705.mail.yahoo.com via HTTP; Thu, 23 Jun 2005 02:25:45 PDT Date: Thu, 23 Jun 2005 02:25:45 -0700 (PDT) From: "Kamal R. Prasad" To: Daniel Eischen , Peter Edwards In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit 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: kamalp@acm.org 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 09:25:47 -0000 --- Daniel Eischen wrote: > 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. > 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. > 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.? regards -kamal > -- > DE > > ------------------------------------------------------------ Kamal R. Prasad UNIX systems consultant http://members.fortunecity.com/kamalp kamalp@acm.org In theory, there is no difference between theory and practice. In practice, there is. ------------------------------------------------------------ __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com