[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: CVS commit: [trunk, wrstuden-revivesa] src/sys
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.
Main Index |
Thread Index |