From owner-freebsd-current@FreeBSD.ORG Sat Jan 21 01:04:08 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from [127.0.0.1] (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 096B416A420; Sat, 21 Jan 2006 01:04:06 +0000 (GMT) (envelope-from davidxu@freebsd.org) Message-ID: <43D18897.3090600@freebsd.org> Date: Sat, 21 Jan 2006 09:04:23 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.12) Gecko/20060117 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Elischer References: <43D05151.5070409@elischer.org> <20060120030105.GA5286@xor.obsecurity.org> <43D0715A.7020302@elischer.org> <20060120061955.GA8687@xor.obsecurity.org> <20060120085226.GQ83922@FreeBSD.org> <43D0AB26.5070407@samsco.org> <20060120095214.GA11088@xor.obsecurity.org> <43D13711.9000509@elischer.org> <43D138C0.9040801@samsco.org> <43D139E2.6020009@elischer.org> In-Reply-To: <43D139E2.6020009@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Gleb Smirnoff , current@freebsd.org, Kris Kennaway Subject: Re: kernel thread as real threads.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Sat, 21 Jan 2006 01:04:09 -0000 Julian Elischer wrote: > > Scott Long wrote: > >> >> Does pthreads allow the programmer to name threads in a user and/or >> kernel visible way? Is this something that is really all that >> important? > > > > There is a way, > but it's more important for kernel threads.. it's nice to see which > is which. > Even in user threads (1:1) if one thread is running away, it's nice to > see which one it is. > > We should have an interface on M:N thread sto allow a process to get > thread stats.. probably implemented as > a management thread or something. (maybe the signal thread could do it). > > I will implement pthread_set_name_np for libthr. but I am not sure you should spend precious time on M:N again, it is already very diffcult to introduce a new scheduler with current framework, putting more constrains only reduces chance for such thing.