On Mon, May 12, 2008 at 02:11:07PM +0100, Andrew Doran wrote: > On Sun, May 11, 2008 at 05:56:02PM -0700, Bill Stouder-Studenmund wrote: > > > On Sun, May 11, 2008 at 02:20:30PM +0100, Andrew Doran wrote: > > > Hi, > > > > > > An easier and cleaner way to handle it would be to maintain the signal > > > mask > > > in each VP's lwpctl block, so that the VP's signal mask can be changed on > > > user context switch without a syscall. If a pending signal become unmasked > > > then a dummy call to sigprocmask() would be needed to clear it and trigger > > > delivery. > > > > Ok, I don't fully picutre what you're suggesting, but I've been thinking > > about signal masking since the commit. For SA processes, signals are > > always unmasked in the kernel. The only time we would want to mask a > > signal would be when we are in the process of delivering one; we mask it > > at least until we start running the signal handler in userland. > > > > What we could do though, and I think is a generalization/simplification of > > what you have in mind, is to just leave signal masks per-lwp and for SA > > processes leave signals unmasked all the time. we instead add a routine in > > the signal delivery code to handle SA processes having the signal masked. > > We then also need only adjust the mask setting routines to do the right > > thing for SA. > > > > I don't think we need a mask per VP, since kernel -> userland signal > > delivery in SA is per-process AFAIK. > > > > So could you please elaborate on what you have in mind? > > I thought I described it reasonably above. Signal masks are thread private > data, aside from the SIGCONT check in sigpost() which is probably not > needed. There's nothing per-process about them. The locking in-kernel might > give a false impression but that's there for historical reasons. I agree that signal masks are thread private data. The thing is that in the SA world, those masks are in userland, so the kernel can't readily see them. Even if we did stuff to load the mask into some comm page (which is racy in all the schemes I can think of), that only tells the kernel about the user threads that are on an lwp. All the ones blocked in userland would be invisible to the kernel. However the only time that a signal is masked in the kernel in an SA process (on any thread, and on every thread) is when we just sent a signal down to the process. So the only time l_sigmask would be non-zero for an SA process would be in the window when we're sending a signal down. Thus we can live w/o the l_sigmask changes I checked in, and instead I can add code to check a process-wide mask iff we go to deliver a signal to an SA thread. That should greatly reduce the code impact of SA. > No special handling is would be needed for sync signals, or async signals > sent from outside the process. Only intra-process, async signals from would > need attention. You could handle them with some combination of polling and a > poke routine that gets the thread's attention if running on a VP. Your very last comment describes a lot of the recent changes I made in libpthread regarding signals. :-) We now poll for signals before going to sleep and my plan is to add a "poke" routine (the periodic timer does an ok job of gettin signals noticed now). Take care, Bill
Attachment:
pgpgup2wjHEuU.pgp
Description: PGP signature