[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 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.
Main Index |
Thread Index |