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

[Andrew Doran <ad%netbsd.org@localhost>]

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,
> > 
> > On Sat, May 10, 2008 at 11:49:09PM +0000, Bill Stouder-Studenmund wrote:
> > 
> > > Log Message:
> > > Initial checkin of re-adding SA. Everything except kern_sa.c
> > > compiles in GENERIC for i386. This is still a work-in-progress, but
> > > this checkin covers most of the mechanical work
> > ...
> > > (changing signalling to be able to accomidate SA's process-wide
> > > signalling
> > 
> > I discussed this with you in private some time ago: the SA code's approach
> > to signal handling is completely ham-fisted and reviving it would involve
> > making invasive code changes in the kernel.
> 
> Well, I think I just made all of them. :-)
> 
> > 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.

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.

Andrew