Date: Wed, 2 Apr 2003 13:25:15 -0800 (PST) From: Julian Elischer <julian@elischer.org> To: Jeff Roberson <jroberson@chesapeake.net> Cc: current@freebsd.org Subject: Re: libthr and 1:1 threading. Message-ID: <Pine.BSF.4.21.0304021316160.16840-100000@InterJet.elischer.org> In-Reply-To: <20030402154406.N64602-100000@mail.chesapeake.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 2 Apr 2003, Jeff Roberson wrote: > On Wed, 2 Apr 2003, Juli Mallett wrote: > > > * De: Jeff Roberson <jroberson@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).
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0304021316160.16840-100000>