From owner-freebsd-threads@FreeBSD.ORG Fri Jun 11 05:15:22 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 B49C216A4CE for ; Fri, 11 Jun 2004 05:15:22 +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 92C7543D55 for ; Fri, 11 Jun 2004 05:15:20 +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 MRDA90G6; Fri, 11 Jun 2004 13:15:18 +0800 Message-ID: <40C94086.7040505@freebsd.org> Date: Fri, 11 Jun 2004 13:17:58 +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 05:15:22 -0000 Daniel Eischen wrote: > On Thu, 10 Jun 2004, Sean McNeil wrote: > > >>On Thu, 2004-06-10 at 21:19, Daniel Eischen wrote: >> >>>The critical section should prevent the signal handler >>>from being invoked. Put some printf()'s in after the >>>sem_post() and in the signal handler(). The signal >>>handler printf()'s should always occur after the sem_post(). >>>Plus, you shouldn't be getting that signal since it >>>should be masked until sigsuspend() is called. >>> >>>Is it getting past sem_post() and into sigsuspend() or not? >>>If it is getting past sem_post(), then I don't think that is >>>your problem. >> >>Here is what I see: >> >>master thread calls pthread_kill with SIGUSR1 and waits on semaphore. >>other thread gets signal and calls sem_post. It yields the scheduler. > > > This is fine as long as this thread doesn't get a signal > until after sem_post(). Being signal safe doesn't mean > that other threads can't be scheduled. > You are right here, I don't think any user visible pthread API should block scheduler to schedule other threads. However, I ever said that sem_wait may need to block out signal when it is holding internal semaphore mutex, because sem_post can be used in signal handler (POSIX explicitly wants this), if the current thread hold the mutex, and a signal arrrives, in signal handler, it calls sem_post(), sem_post try to hold the mutex again, it would be failure, then semaphore may be in inconsistent state. This is a corner case caused by sem_post can be used signal handler. David Xu