From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 22 14:25:29 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 0DEF416A41C for ; Wed, 22 Jun 2005 14:25:29 +0000 (GMT) (envelope-from eischen@vigrid.com) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id C591D43D55 for ; Wed, 22 Jun 2005 14:25:26 +0000 (GMT) (envelope-from eischen@vigrid.com) 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 j5MEPJHq029069; Wed, 22 Jun 2005 10:25:19 -0400 (EDT) Date: Wed, 22 Jun 2005 10:25:19 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Norbert Koch In-Reply-To: <000801c5772a$23dac9c0$4801a8c0@ws-ew-3.W2KDEMIG> 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, Peter Edwards Subject: RE: Nagios and threads X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list 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:25:29 -0000 On Wed, 22 Jun 2005, Norbert Koch wrote: > > [snip] > > > at least some assumptions that the child won't be > > > doing much before > > > execing or exiting. (But Im sure one of the > > > > 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. > > > > regards > > -kamal > > >From "Programming with POSIX Threads" [David R. Butenhof]: > > p.197-198: > ... Avoid using fork in a threaded program (if you can) > unless you intend to exec a new program immediately > ... Pthreads does not "terminate" the other threads > in a forked process. ... They simple cease to exist. > ... The state of mutexes is not affected by a fork. If > it was locked in the parent it is locked in the child! Yes, and realize that both libc and libpthread are consumers themselves of mutexes (and CVs). Also, some system calls are wrapped by libpthread to provide cancellation points. Unless you exec after the fork, you may be relying on inconsistent mutex state. -- DE