From owner-freebsd-threads@FreeBSD.ORG Mon Apr 18 15:02:11 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 C8BB416A4CE; Mon, 18 Apr 2005 15:02:11 +0000 (GMT) Received: from mxsf38.cluster1.charter.net (mxsf38.cluster1.charter.net [209.225.28.165]) by mx1.FreeBSD.org (Postfix) with ESMTP id 259DC43D39; Mon, 18 Apr 2005 15:02:11 +0000 (GMT) (envelope-from archie@dellroad.org) Received: from mxip08.cluster1.charter.net (mxip08a.cluster1.charter.net [209.225.28.138])j3IF291M024609; Mon, 18 Apr 2005 11:02:09 -0400 Received: from cable-68-113-94-164.mtv.al.charter.com (HELO InterJet.dellroad.org) (68.113.94.164) by mxip08.cluster1.charter.net with ESMTP; 18 Apr 2005 11:00:08 -0400 X-Ironport-AV: i="3.92,110,1112587200"; d="scan'208"; a="863273741:sNHT20863552" Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.2.2.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id JAA52079; Mon, 18 Apr 2005 09:47:44 -0500 (CDT) Received: from [127.0.0.1] (localhost [127.0.0.1])j3IElhZK010376; Mon, 18 Apr 2005 09:47:44 -0500 (CDT) (envelope-from archie@dellroad.org) Message-ID: <4263C88F.4050007@dellroad.org> Date: Mon, 18 Apr 2005 09:47:43 -0500 From: Archie Cobbs User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.3) Gecko/20041129 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Eischen References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2005 15:02:11 -0000 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? If it does, can you show me in which FreeBSD releases the bug is fixed? 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. In any case, if the thread library is not always sending synchronous signals to the generating thread then no further research is necessary. Thanks, -Archie __________________________________________________________________________ Archie Cobbs * CTO, Awarix * http://www.awarix.com