From owner-freebsd-threads@FreeBSD.ORG Wed Apr 16 11:16:34 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8CC3C37B40B; Wed, 16 Apr 2003 11:16:34 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id D47B243F93; Wed, 16 Apr 2003 11:16:29 -0700 (PDT) (envelope-from eischen@pcnet1.pcnet.com) Received: from pcnet1.pcnet.com (localhost [127.0.0.1]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h3GIGQBg001912; Wed, 16 Apr 2003 14:16:26 -0400 (EDT) Received: from localhost (eischen@localhost)h3GIGQYU001909; Wed, 16 Apr 2003 14:16:26 -0400 (EDT) Date: Wed, 16 Apr 2003 14:16:26 -0400 (EDT) From: Daniel Eischen To: Jeff Roberson In-Reply-To: <20030416123956.Q76635-100000@mail.chesapeake.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: deischen@freebsd.org cc: jeff@freebsd.org cc: freebsd-threads@freebsd.org cc: John Polstra Subject: Re: May I add pthread_[gs]etconcurrency to the threads libraries? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2003 18:16:34 -0000 On Wed, 16 Apr 2003, Jeff Roberson wrote: > On Wed, 16 Apr 2003, Daniel Eischen wrote: > > > On Wed, 16 Apr 2003, John Polstra wrote: > > > > > Hi Guys, > > > > > > Sergey Osokin sent me patches to add the standard > > > pthread_[gs]etconcurrency functions to our various threads > > > libraries. I reviewed them and they're OK. The functions don't do > > > anything significant, but they fill the need for this part of the > > > API. > > > > > > OK if I commit them this weekend? The changes don't change anything > > > else. They just add stuff. > > > > I'm about to implement them for real in libpthread. I'd appreciate > > you not adding them to that. I've got a slew of other changes that > > I want add to it very soon. > > > > They don't seem to make sense for libthr and libc_r unless it > > returns ENOTSUP. libthr is 1:1, so it is meaning less there > > as well as libc_r. > > It is not meaningless. Please go ahead and implement stubs if you like. > I intended to implement a thr_setconcurrency that these can eventually > use. I was just going to implement it as a simple counter on the proc > instead of using a full blown KSE structure just for this. > > 1:1 means one kernel thread for each user thread. It doesn't say anything > about how many of those threads may run at a given time. It also doesn't > force any scheduling scope or scheduling algorithm. OK, I was under the impression that libthr would always schedule threads (KSEs) to as many processors as possible. It'd be neat to eventually softly bind them (KSE's in general) too :-) -- Dan Eischen