From owner-freebsd-hackers@FreeBSD.ORG Sat May 24 02:55:36 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7A7A737B408 for ; Sat, 24 May 2003 02:55:36 -0700 (PDT) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D05043F85 for ; Sat, 24 May 2003 02:55:35 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from user-38lc19n.dialup.mindspring.com ([209.86.5.55] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19JVkQ-0003hM-00; Sat, 24 May 2003 02:55:31 -0700 Message-ID: <3ECF4149.EDCDD1B6@mindspring.com> Date: Sat, 24 May 2003 02:54:17 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Daniel Eischen References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a492039876ae40d184f717725d6ea2277b387f7b89c61deb1d350badd9bab72f9c350badd9bab72f9c cc: freebsd-hackers@freebsd.org cc: Dan Nelson cc: Julian Elischer Subject: Re: libkse and SMP (was Re: USB bulk read & pthreads) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 May 2003 09:55:36 -0000 Daniel Eischen wrote: > On Fri, 23 May 2003, Terry Lambert wrote: > > I'm rereading it, but I don't see that interpretation. > > > > I guess if both you and Julian both called me on it, I must > > have misexpressed myself, but I currently don't understand > > how. 8-|. > > I think it was the part about "a single CPU system with > PTHREAD_SCOPE_PROCESS (the default) can still get itself > blocked in the kernel by a single blocking call" without > mentioning that it won't block other scope process > threads from being run. OK... this I don't get. If the scope is process, and you are implementing M:N, and N == 1, my understanding of the code is that it will block exactly the same as libc_r. If it won't (and I'm prepared to believe this), then I'd like to know "why not?"; it should be that there is a single scheduling object, no? Reading the code, I don't get that there will be the ability to do multiple returns. Is it that a KSEG is intended to represent a quantum? If so, I've just had an epiphany as to why you would want KSEG's at all in the first place (I've never agreed with Julian on KSEG's, since the earliest days, and I've only reluctantly accepted their necessity as an artifact of scheduling priority differences for a strictest compliance with POSIX mandated semantics -- hence my defense of them to Jeff when he wanted to change the kernel code to make them semi-impossible). -- Terry