From owner-freebsd-threads@FreeBSD.ORG Wed Aug 20 14:44:33 2003 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 DC54716A4BF; Wed, 20 Aug 2003 14:44:32 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id B78DE43F85; Wed, 20 Aug 2003 14:44:31 -0700 (PDT) (envelope-from davidxu@FreeBSD.org) Received: from localhost (davidxu@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h7KLiTUp008139; Wed, 20 Aug 2003 14:44:30 -0700 (PDT) (envelope-from davidxu@FreeBSD.org) From: David Xu To: deischen@FreeBSD.org, Daniel Eischen Date: Thu, 21 Aug 2003 05:47:31 +0800 User-Agent: KMail/1.5.2 References: In-Reply-To: MIME-Version: 1.0 Message-Id: <200308210547.25134.davidxu@FreeBSD.org> Content-Type: Multipart/Mixed; boundary="Boundary-00=_zx+Q/XlcOGFLZ07" X-Content-Filtered-By: Mailman/MimeDel 2.1.1 cc: threads@FreeBSD.org Subject: buffered signal X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: davidxu@FreeBSD.org List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2003 21:44:33 -0000 --Boundary-00=_zx+Q/XlcOGFLZ07 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Dan, I am thinking about a problem with buffered signals. Suppose if libkse is in critical region and signal A and B arrived, then A and B are buffered. Later, after thread leaves critical region, thread starts to process buffered signal A, before it can process A, another signal C arrived, so thread starts to process signal C, then in signal handler of C, it masks signal A in kernel and returns, so signal won't be processed in future because we current test kernel signal to see if A is masked. Though A is already delivered to userland but will never be processed! we never check this blocked signal A in pthread_sigmask,and sigpending() and sigsuspend(), sigwait...., possible we can repost it to kernel, but may have side effect, for example, it would lose orignal siginfo meaning. When A is masked, it must be masked by a signal handler by another new signal but not by normal user code, because buffered signal can only happen when it is executing libkse code, and further think that changing signal mask in signal handler is always not stable and not suggested, I think we can always process all buffered signals and ignore kernel signal mask. I am not very sure if it is legal, but shouldn't have problem in real world. ;-) Regards, David Xu --Boundary-00=_zx+Q/XlcOGFLZ07--