Date: Sat, 21 Jan 2006 09:04:23 +0800 From: David Xu <davidxu@freebsd.org> To: Julian Elischer <julian@elischer.org> Cc: Gleb Smirnoff <glebius@freebsd.org>, current@freebsd.org, Kris Kennaway <kris@obsecurity.org> Subject: Re: kernel thread as real threads.. Message-ID: <43D18897.3090600@freebsd.org> In-Reply-To: <43D139E2.6020009@elischer.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43D18897.3090600>