From owner-freebsd-threads@FreeBSD.ORG Mon Apr 18 17:56:27 2005 Return-Path: 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 B64EB16A4CE; Mon, 18 Apr 2005 17:56:27 +0000 (GMT) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 256E443D46; Mon, 18 Apr 2005 17:56:27 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) j3IHuPAB029156; Mon, 18 Apr 2005 13:56:25 -0400 (EDT) Date: Mon, 18 Apr 2005 13:56:25 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Archie Cobbs In-Reply-To: <4263C88F.4050007@dellroad.org> 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: David Xu cc: freebsd-threads@freebsd.org Subject: Re: Bug with pthread_getspecific() and signals X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 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, 18 Apr 2005 17:56:27 -0000 On Mon, 18 Apr 2005, Archie Cobbs wrote: > Daniel Eischen wrote: > > I don't think libc_r differentiates between synchronous > > and asynchronous signals. It'll look for threads in > > sigwait(), then sigsuspend(), then any thread with the > > signal unmasked. > > Well that would certainly explain my problem. By the way, this application > is a Java virtual machine, trying to use signals to detect null pointer > dereferences (and divide by zero). How is one supposed to do this if > synchronous signals are not delivered to the thread that generated them? > It then becomes impossible to detect in which thread the signal occurred. > > Is this a bug in libc_r? Does POSIX not specify this "same thread" behavior > for synchronous signals? Yes, yes. > If it does, can you show me in which FreeBSD releases the bug is fixed? I don't know if it ever got fixed in libc_r. > If not, how do other applications implement this?? > > > Try -stable or -current with libpthread and libthr. > > Unfortunately I don't have easy access to either such machine. > I've been told that the same problem occurs with libthr though. It should work correctly in both libpthread and libthr. libc_r is not being maintained. -- DE