FWD: Re: May I add pthread_[gs]etconcurrency to the threads libr

[Daniel Eischen]

On Thu, 17 Apr 2003, Sergey A. Osokin wrote:
> On Thu, Apr 17, 2003 at 05:46:07AM -0400, Daniel Eischen wrote:
> > On Thu, 17 Apr 2003, Sergey A. Osokin wrote:
> > > On Wed, Apr 16, 2003 at 09:44:09AM -0700, John Polstra wrote:
> > > > 
> > > > FYI -- Dan Eischen asked me not to commit your changes to
> > > > libpthread.  I then told him he should at least try to use your man
> > > > page and credit you appropriately.
> > > > 
> > > > I also told him that he's wrong about returning ENOTSUP, according
> > > > to the standards.
> > > 
> > > So, I can't understand Daniel's position.
> > 
> > Because usually POSIX functions are either fully implemented or not
> > implemented at all.  I took a look at the POSIX spec and this is not
> > the case with pthread_[gs]setconcurrency; they do match what you
> > say.
> > 
> > > AFAIK at this time real implementation of that fuctions not yet avaliable.
> > > If it not yet avaliable - I think we must use this implementation.
> > > In near future, when the other implementations to be avaliable,
> > > somebody immediatly replace old fake implementation with new real one.
> > 
> > You missed my response that said I am implementing them "for real"
> > (not fake) and that I had a slew of other changes.  I am a day or
> > so away from commiting my changes (this is for libpthread, not
> > libc_r or libthr).
> 
> Thanks, i see. So, what about other (not libpthread) implementations
> of threads (like libc_r and libthr)?

It's OK for those; libc_r will never need anything other than
a fake one, and Jeff said it was OK for libthr (Jeff, correct
me if I'm wrong).

-- 
Dan Eischen