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

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

On Mon, May 12, 2008 at 09:42:12AM -0700, Bill Stouder-Studenmund wrote:

> 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)

Not a problem since it's thread private data. Everything can be deferred or
restartable. A single flag to block signals while a mask transition is in
progress is enough.

> , 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.

Not a problem: in an SA scheme there is no requirement for the kernel to
know about intrathread signals.

> 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.

Adding SA specific hacks into the signal code is ugly. Sun went that way and
the unmanageability of the approch was a large factor in their decision to
give up on M:N threads.

Andrew