From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 22 15:47:56 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 C515E16A43E; Mon, 22 Aug 2005 15:47:56 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F00B43D62; Mon, 22 Aug 2005 15:47:54 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1]) by harmony.village.org (8.13.3/8.13.3) with ESMTP id j7MFjvBY049786; Mon, 22 Aug 2005 09:45:58 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 22 Aug 2005 09:46:04 -0600 (MDT) Message-Id: <20050822.094604.112623156.imp@bsdimp.com> To: deischen@freebsd.org From: "M. Warner Losh" In-Reply-To: References: <20050822.080938.95905450.imp@bsdimp.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.village.org [127.0.0.1]); Mon, 22 Aug 2005 09:45:58 -0600 (MDT) 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 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:47:56 -0000 In message: Daniel Eischen writes: : 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. Is there some way to flip a switch and get an abort in all the non-async-safe-safe functions in libc :-) Warner