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'm perfectly happy to rip out what I checked in and do something we feel is better. I just need to have a clearer idea in my head what you have in mind. ;-) > > re-adding includes of sys/sa.h and savar.h). > > The majority that were removed were there only because of unusual types in > syscallargs.h, that should be fixed properly. Ok, the types in questio are stack_t and sa_upcall_t. Where do you suggest I include them? Take care, Bill
Attachment:
pgpHUJcLWsZs3.pgp
Description: PGP signature