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. Agreed. > > 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, Bill
Attachment:
pgpiFythtSTM0.pgp
Description: PGP signature