From owner-freebsd-threads@FreeBSD.ORG Mon Oct 24 13:49:33 2005 Return-Path: X-Original-To: freebsd-threads@freebsd.org Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B338C16A41F; Mon, 24 Oct 2005 13:49:33 +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 09B1C43D6A; Mon, 24 Oct 2005 13:49:32 +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.5/8.13.5/NETPLEX) with ESMTP id j9ODnVhk027165; Mon, 24 Oct 2005 09:49:31 -0400 (EDT) Date: Mon, 24 Oct 2005 09:49:31 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Marc Olzheim In-Reply-To: <20051024121145.GB25866@stack.nl> 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: Marc Olzheim , David Xu , freebsd-threads@freebsd.org Subject: Re: threads/76690: fork hang in child for (-lc_r & -lthr) X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2005 13:49:33 -0000 On Mon, 24 Oct 2005, Marc Olzheim wrote: > I'm not interested in politics, I just want this fixed. Well it is fixed > in my local source tree, but since FreeBSD 4.x is still the only FreeBSD > version stable enough for me (see showstoppers.html), I'm still bound to > libc_r and whether you want to deprecate it in -CURRENT or not is none > of my concern. > > Well, in fact I'm for it, since KSE is a very suitable replacement > indeed. Still, *repeating* that same "deprecated!" response over and > over does not help anyone on FreeBSD 4.x. > > > So: I have a fix for the bug in 4.x. If you don't want it fixed, close > the PR and don't do anything about it, otherwise, let someone who cares > about it answer my mail, as I asked for in the first place: I'm not interested in maintaining libc_r, but I looked at the fix. It exports symbols into the application namespace (those without leading underscores). It also looks to me like an application bug since you can only use async signal safe functions in the child after a fork() from a threaded application and before an exec() of some sort. -- DE