From owner-freebsd-current@FreeBSD.ORG Wed Apr 2 14:42:11 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 0156337B401; Wed, 2 Apr 2003 14:42:11 -0800 (PST) Received: from mail.chesapeake.net (chesapeake.net [205.130.220.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id AAC8043FCB; Wed, 2 Apr 2003 14:42:09 -0800 (PST) (envelope-from jroberson@chesapeake.net) Received: from localhost (jroberson@localhost) by mail.chesapeake.net (8.11.6/8.11.6) with ESMTP id h32Mg5R55681; Wed, 2 Apr 2003 17:42:05 -0500 (EST) (envelope-from jroberson@chesapeake.net) Date: Wed, 2 Apr 2003 17:42:05 -0500 (EST) From: Jeff Roberson To: Daniel Eischen In-Reply-To: Message-ID: <20030402173720.W64602-100000@mail.chesapeake.net> 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:42:11 -0000 On Wed, 2 Apr 2003, Daniel Eischen wrote: > 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(). I had not seen anyone mention this. If this is the case then I suggest the masks and pending sets be kept in user space. You can install blank handlers for everything so that they are kept pending until the uts has a chance to pick them up in the upcall. If you really want a process wide mask allow me to do it. The single code is quite tricky and it's already been butchered enough. I think we should discuss this a bit more first though. Cheers, Jeff