From owner-freebsd-current@FreeBSD.ORG Wed Apr 2 14:36:56 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 9BA5A37B401; Wed, 2 Apr 2003 14:36:56 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id D80A843FA3; Wed, 2 Apr 2003 14:36:55 -0800 (PST) (envelope-from eischen@pcnet1.pcnet.com) Received: from pcnet1.pcnet.com (localhost [127.0.0.1]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h32MahBg011853; Wed, 2 Apr 2003 17:36:44 -0500 (EST) Received: from localhost (eischen@localhost)h32MahlH011849; Wed, 2 Apr 2003 17:36:43 -0500 (EST) Date: Wed, 2 Apr 2003 17:36:43 -0500 (EST) From: Daniel Eischen To: Jeff Roberson In-Reply-To: <20030402172900.I64602-100000@mail.chesapeake.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Robert Watson cc: Julian Elischer cc: Alexander Leidinger cc: csujun@21cn.com cc: current@freebsd.org 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 22:36:56 -0000 On Wed, 2 Apr 2003, Jeff Roberson wrote: > On Wed, 2 Apr 2003, Julian Elischer wrote: > > > > > > > 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. > > > > Then set the mask to be the same on all threads in the process. The mask > is set in swapcontext though so it seems reasonable to me that it is > atomically updated when you schedule a new user thread on a kse. Jeff, are you _listening_ to us? We've said multiple times that the UTS does not enter the kernel when performing thread switches. The UTS does NOT use setcontext(), getcontext(), or swapcontext(). -- Dan Eischen