From owner-freebsd-threads@FreeBSD.ORG Fri Jun 11 08:24:35 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 D09B916A4CE for ; Fri, 11 Jun 2004 08:24:35 +0000 (GMT) Received: from exchhz01.viatech.com.cn (ip-40-162-97-218.anlai.com [218.97.162.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id 04B8943D31 for ; Fri, 11 Jun 2004 08:24:33 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from freebsd.org (DAVIDWNT [10.4.1.99]) by exchhz01.viatech.com.cn with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id MRDA9062; Fri, 11 Jun 2004 16:24:10 +0800 Message-ID: <40C96CCA.9060704@freebsd.org> Date: Fri, 11 Jun 2004 16:26:50 +0800 From: David Xu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030723 Thunderbird/0.1 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: Sean McNeil 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:24:35 -0000 This proves thread programming is so complicate, it is no longer streamline. ;-) David Xu Daniel Eischen wrote: > On Fri, 11 Jun 2004, Sean McNeil wrote: > > >>OK, I think I have it figured out.... >> >>The problem is, that when the first signal handler, SIGUSR1, is run > > the > >>SIGUSR2 signal is blocked. I think this is what Daniel was trying to > > ^ not > > >>say, or I didn't provide enough information for him to catch it. So, >>I've fixed the sigaction call to unblock SIGUSR2 while SIGUSR1 is > > going > ^^^^^^^ block > > >>and rearranged a few things: >> >> me->stop_info.signal = 0; >> me->stop_info.last_stop_count = my_stop_count; >> >> /* Tell the thread that wants to stop the world that this */ >> /* thread has been stopped. Note that sem_post() is */ >> /* the only async-signal-safe primitive in LinuxThreads. */ >> sem_post(&GC_suspend_ack_sem); >> >>#if DEBUG_THREADS >> GC_printf2("Waiting for restart #%d of 0x%lx\n", my_stop_count, > > my_thread); > >>#endif >> >> /* Wait until that thread tells us to restart by sending */ >> /* this thread a SIG_THR_RESTART signal. */ >> if (sigfillset(&mask) != 0) ABORT("sigfillset() failed"); >> if (sigdelset(&mask, SIG_THR_RESTART) != 0) ABORT("sigdelset() > > failed"); > >># ifdef NO_SIGNALS >> if (sigdelset(&mask, SIGINT) != 0) ABORT("sigdelset() failed"); >> if (sigdelset(&mask, SIGQUIT) != 0) ABORT("sigdelset() failed"); >> if (sigdelset(&mask, SIGTERM) != 0) ABORT("sigdelset() failed"); >> if (sigdelset(&mask, SIGABRT) != 0) ABORT("sigdelset() failed"); >># endif >> >> while (me->stop_info.signal != SIG_THR_RESTART) { >> sigsuspend(&mask); /* Wait for signal */ >> } >> >>There might still be a bug that I'm just hiding. I think that the >>problem is while in the handler for SIGUSR1 and someone calls >>pthread_kill with SIGUSR2, the signal isn't marked as pending because > > it > >>is masked off. It appears to rely on the following behavior: > > ^^^^^^^^^^ > > 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.