From owner-freebsd-current@FreeBSD.ORG Wed Apr 2 13:15:26 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DD22137B401; Wed, 2 Apr 2003 13:15:26 -0800 (PST) Received: from sccrmhc03.attbi.com (sccrmhc03.attbi.com [204.127.202.63]) by mx1.FreeBSD.org (Postfix) with ESMTP id D8EAE43F93; Wed, 2 Apr 2003 13:15:25 -0800 (PST) (envelope-from julian@elischer.org) Received: from interjet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by sccrmhc03.attbi.com (sccrmhc03) with ESMTP id <20030402211524003001vdbve>; Wed, 2 Apr 2003 21:15:25 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id NAA18030; Wed, 2 Apr 2003 13:15:23 -0800 (PST) Date: Wed, 2 Apr 2003 13:15:22 -0800 (PST) From: Julian Elischer To: Juli Mallett In-Reply-To: <20030402143527.A96165@FreeBSD.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Jeff Roberson cc: csujun@21cn.com cc: Robert Watson cc: current@freebsd.org cc: Alexander Leidinger Subject: Re: libthr and 1:1 threading. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2003 21:15:27 -0000 On Wed, 2 Apr 2003, Juli Mallett wrote: > * De: Jeff Roberson [ 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. I think this IS a problem. We need a per-process mask. to block signals that no thread is interested in. Since M:N threads do not have a kernel thread for each userland thread, there is nowhere to store this info any more. I'd be happy to have it be a per-ksegrp mask actually.. (to help deliver the signal to the right group to lower the interaction between UTS's in different groups.)