From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 22 15:36:26 2005 Return-Path: X-Original-To: freebsd-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 74ED016A41F for ; Mon, 22 Aug 2005 15:36:26 +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 1679D43D48 for ; Mon, 22 Aug 2005 15:36:25 +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 j7MFaNLr015006; Mon, 22 Aug 2005 11:36:23 -0400 (EDT) Date: Mon, 22 Aug 2005 11:36:23 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: "M. Warner Losh" In-Reply-To: <20050822.080938.95905450.imp@bsdimp.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: freebsd-hackers@freebsd.org, lists@nbux.com Subject: Re: nagios and freebsd threads issue : help please ... 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: Mon, 22 Aug 2005 15:36:26 -0000 On Mon, 22 Aug 2005, M. Warner Losh wrote: > So there's something in the list, I've gone through and done a call > tree analysis to show the extensive and pervastive nature of the > functions that nagios calls after fork. I don't know if these are all > problems or not, since I don't know if some of these functions might > be called before the first thread is created with pthread_create. > However, any that are called after that clearly have undefined > behavior. Note that we (David Xu and myself) took a different approach to handling fork() in libpthread (and probably libthr) than was done in libc_r. We thought it better not to try and reinitialize libpthread (and to some extent libc) because it is messy and to expose non-portable applications. -- DE