Date: Wed, 16 Apr 2003 12:42:40 -0400 (EDT) From: Jeff Roberson <jroberson@chesapeake.net> To: Daniel Eischen <eischen@pcnet1.pcnet.com> Cc: John Polstra <jdp@polstra.com> Subject: Re: May I add pthread_[gs]etconcurrency to the threads libraries? Message-ID: <20030416123956.Q76635-100000@mail.chesapeake.net> In-Reply-To: <Pine.GSO.4.10.10304161232120.14483-100000@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Cheers, Jeff
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030416123956.Q76635-100000>