tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: CVS commit: [trunk, wrstuden-revivesa] src/sys

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,


Attachment: pgpgup2wjHEuU.pgp
Description: PGP signature

Home | Main Index | Thread Index | Old Index