Date: Thu, 21 Aug 2003 05:47:31 +0800 From: David Xu <davidxu@FreeBSD.org> To: deischen@FreeBSD.org, Daniel Eischen <eischen@vigrid.com> Cc: threads@FreeBSD.org Subject: buffered signal Message-ID: <200308210547.25134.davidxu@FreeBSD.org> In-Reply-To: <Pine.GSO.4.10.10308200914310.6461-100000@pcnet5.pcnet.com> References: <Pine.GSO.4.10.10308200914310.6461-100000@pcnet5.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200308210547.25134.davidxu>