tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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

On Thu, May 22, 2008 at 04:04:15PM +0100, Andrew Doran wrote:
> 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:
> > 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.

This is part of what I'm not getting. I don't think that signal delivery 
was one of the things that was vilely-wrong in our old SA code. Yes, I've 
fixed a few bugs, but they haven't been structureal bugs. They've been "I 
never thought of this case" kinda bugs.

So other than the overhead of l_sigmask being a pointer vs a structure in 
the lwp (something which I firmly believe we won't need to bring back), 
I'm not sure what was ugly about what we used to have. I probably am 
missing something, and I'm not sure what. :-)

So what was so hideous about our old signal code?

Take care,


Attachment: pgpiFythtSTM0.pgp
Description: PGP signature

Home | Main Index | Thread Index | Old Index