From owner-freebsd-current@FreeBSD.ORG Sat Oct 28 02:48:05 2006 Return-Path: X-Original-To: current@freebsd.org 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 ED84516A407 for ; Sat, 28 Oct 2006 02:48:05 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 573A643D67 for ; Sat, 28 Oct 2006 02:48:05 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.13.7/8.13.7/NETPLEX) with ESMTP id k9S2m1hO008230; Fri, 27 Oct 2006 22:48:01 -0400 (EDT) Date: Fri, 27 Oct 2006 22:48:01 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Paul Allen In-Reply-To: <20061027213125.GI30707@riyal.ugcs.caltech.edu> Message-ID: References: <45425D92.8060205@elischer.org> <20061027201838.GH30707@riyal.ugcs.caltech.edu> <20061027213125.GI30707@riyal.ugcs.caltech.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-2.0.2 (mail.ntplx.net [204.213.176.10]); Fri, 27 Oct 2006 22:48:01 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: Julian Elischer , current@freebsd.org Subject: Re: Comments on the KSE option X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Oct 2006 02:48:06 -0000 On Fri, 27 Oct 2006, Paul Allen wrote: > From Daniel Eischen , Fri, Oct 27, 2006 at 04:41:16PM -0400: >> On Fri, 27 Oct 2006, Paul Allen wrote: >> >>>> From Julian Elischer , Fri, Oct 27, 2006 at >>>> 12:27:14PM -0700: >>>> The aim of the fair scheduling code is to ensure that if you, as a user, >>>> make a process that starts 1000 threads, and I as a user, make an >>>> unthreaded process, then I can still get to the CPU at somewhat similar >>>> rates to you. A naive scheduler would give you 1000 cpu slots and me 1. >>> >>> Ah. Let me be one of the first to take a crack at attacking this idea as >>> a mistake. >> >> No, it is POSIX. You, the application, can write a program with >> system scope or process scope threads and get whatever you behavior >> you want, within rlimits of course. > So your argument is: "if I can find a spec that does it, its right" > Sorry but if you participated in more spec writing--I do, in the IEEE-- > you'd realize that was not a good position from which to argue. Plenty > of mistakes are made in specs. If you want to argue about it, go argue in the POSIX working group, not here. We have what we have, and it IS something that is important to allow. Nothing about what you said previously is prevented by allowing both system and process scope threading. There are those that really want POSIX threading semantics, so please don't tell me that I can't have them. I certainly am not going to argue for removing system scope threading (which according to Julian is what libthr defaults to). -- DE