libkse -> libpthreads

[Jeff Roberson]

On Mon, 21 Apr 2003, Daniel Eischen wrote:

> 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.

thr system calls are native threads.  libthr implements pthreads.  I don't
really care what you call it now.  Go ahead and call it libpthreads.

>
> > > 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
>
> _______________________________________________
> freebsd-threads at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-threads
> To unsubscribe, send any mail to "freebsd-threads-unsubscribe at freebsd.org"
>