libthr and 1:1 threading.

[Julian Elischer]

On Wed, 2 Apr 2003, Jeff Roberson wrote:

> On Wed, 2 Apr 2003, Juli Mallett wrote:
> 
> > * De: Jeff Roberson <jroberson at chesapeake.net> [ Data: 2003-04-02 ]
> > 	[ Subjecte: Re: libthr and 1:1 threading. ]
> > > On Wed, 2 Apr 2003, Terry Lambert wrote:
> > > > Also, any ETA on the per process signal mask handing bug in
> > > > libthr?  Might not be safe to convert everything up front, in
> > > > a rush of eager enthusiasm...
> > >
> > > Which bug is that?  I'm not aware of it.
> >
> > I think Terry is referring to the Uncertainty & Doubt as if it were
> > a bug over the lack of a process sigmask (moved into the threads),
> > as raised by the M:N group.
> 
> POSIX specifically says that the signal mask is per thread.  I'd be very
> surprised if the 1:1 sigmask/sigpending stuff was wrong.  I don't think
> signal handling in M:N has really been totally worked out.  Their concerns
> were more like 'how do we do this given the new signal restructuring'
> 
> Perhaps I should start quoting posix.  I wonder what my legal rights
> are given the copyright. hm..

Posix defines the interface at the 'top' of the library.

In M:N threads, the process gets signals that are not blocked by any
thread. There may be 10,000 threads, only 3 of which the kernel has any
knowledge. The signal needs to be checked againsta a per-process mask
before being routed to the UTS for forwarding to the apropriate thread.

To achieve that efficiently we will have a per-process mask, and use
that. 1:1 threads (and non-threaded processes) will continue to use
the per-thread mask. On switching to M:N mode, we'll just clone the
active thread's mask into the process mask. No biggie.. just needs code
:-)

When M:N threads are involved psignal() will just check against a
different mask, and delivery is already handled in a different manner.

The UTS will update the per-process mask as needed as only it knows
what all the threads are masking (since the kernel doesn't even know
what threads exist).