libkse -> libpthreads

[Daniel Eischen]

On Tue, 22 Apr 2003, Narvi wrote:

> 
> On Mon, 21 Apr 2003, Daniel Eischen wrote:
> 
> > On Mon, 21 Apr 2003, Julian Elischer wrote:
> >
> > >
> > > WE have a small problem.. when we started we had only on  pthreads
> > > package and libKSE was teh heir..
> >
> > No, libkse WAS libpthread.  We renamed the library
> > temporarily until it was proven to work reasonably
> > well (I did the commit that renamed it).
> >
> > > now we have to live with libthr in the picture.
> > > it is possible that we should think of a naming scheme that
> > > allows all 3 libraries to have meaningful related names
> > >
> > > libc_r -> libpthreadM1
> > > libthr -> libpthreadMM
> > > libkse -> libpthreadMN
> > >
> > > or something.
> >
> > The current naming scheme is fine.  Libc_r is already
> > a well known name along with its shortcomings.  Solaris
> > uses libthread for 1:1 as far as I can tell which would
> > seem to match libthr, and libpthread is the POSIX threads
> > library whose goal is to support POSIX as fully as
> > possible (scope process and scope system).
> >
> 
> Solaris libthr is not a 1:1 thread library - the difference between

Yes, I believe it now is.

> libpthread and libthread is that libthread implements UI (sometimes also
> called Solaris) threads, and not pthreads.

And libthr threads are sorta like native threads.

> > I would object to libpthread{M1,MM,MN}.  We already
> > had a name for libpthread.  Libthr can live fine as
> > libthr or libthread.
> >
> 
> No - if both provide the same API with potentially different
> implementation tradeoffs, then ythe libraries should be installed with
> different names and a symlink to the prefered one installed.

The default library, whatever that may be, is easily changed
by setting PTHREAD_LIBS, which the ports system knows about.

> At least for the moment it is not clear that one of teh libraries is a
> winner and will eliminate the other,

It was never intended for libthr to eliminate libpthread.
In fact, it was advertised as an interim solution to buy
us time.  Trying to work around libthr in the kernel hasn't
really bought us time though.

> so it would be evil to force people
> to explicitly link against one or the other causing future compatibility
> problems. Both provide the same pthreads API so there is no reasonable
> case for demanding that one of them can't have its SONAME be
> libpthpread.so.1

We can, in libpthread, build it so that every thread is 1:1.
True, we might not be able to do this without a small
amount of overhead right now, but it will be possible in the
future.  If built that way, we can install it as libthr so
that any application relying on libthr.so.1 will still have
it there.  This has been one of my goals for some time.

I want libpthread to get out there for 5.1.  I want to see
those bug reports roll in, so that by the time 5.2 (-stable)
comes around we have a good handle on what the problems are
and have addressed them.  We have 3 people (David Xu, Julian,
and myself) wanting to maintain this and keep it moving
forward.  I don't want to see it go away.

-- 
Dan Eischen