From owner-freebsd-threads@FreeBSD.ORG Fri Jun 11 08:37:59 2004 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 3C4EE16A4CE; Fri, 11 Jun 2004 08:37:59 +0000 (GMT) Received: from mail.mcneil.com (rrcs-west-24-199-45-54.biz.rr.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1B24D43D53; Fri, 11 Jun 2004 08:37:59 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id 8309FFD087; Fri, 11 Jun 2004 01:37:42 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09799-08; Fri, 11 Jun 2004 01:37:42 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id 07CC4FD012; Fri, 11 Jun 2004 01:37:41 -0700 (PDT) From: Sean McNeil To: Daniel Eischen In-Reply-To: References: Content-Type: text/plain Message-Id: <1086943061.10026.45.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 11 Jun 2004 01:37:41 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com cc: David Xu cc: freebsd-threads@freebsd.org Subject: Re: signal handler priority issue 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: Fri, 11 Jun 2004 08:37:59 -0000 On Fri, 2004-06-11 at 01:34, Daniel Eischen wrote: > On Fri, 11 Jun 2004, Sean McNeil wrote: > > > > > > No, the problem is because SIGUSR2 is _not_ blocked. I read > > > "masked off" as "blocked" (the desired behavior). If the > > > signal handler runs, that means that the signal is not blocked. > > > Your goal is to prevent the signal handler (for SIGUSR2) from > > > running until sigsuspend() is hit. Once sigsuspend() is hit, > > > then SIGUSR2 becomes unblocked, the signal handler is run, > > > and sigsuspend() returns. > > > > This is exactly what boehm-gc is doing. There must be something else > > lurking in here that I've missed. I have to keep looking at it. > > Put print statements just before the sigsuspend() as well as > keeping it in the signal handler for SIGUSR2. If you see > the print from SIGUSR2 handler before you see the one from > just before sigsuspend(), you know that the signal mask > is not correct when SIGUSR1 is handled. > > Signing off for tonight... I think I may have it. I think the sigsuspend is releasing before the signal handler is executed so that the SIGUSR1 handler just loops and waits for the signal again. There may also be an optimization problem with the loop test not being volatile. Checking both posibilities now. Thanks for all the help.