Date: Mon, 21 Apr 2003 19:08:17 -0400 (EDT) From: Jeff Roberson <jroberson@chesapeake.net> To: Daniel Eischen <eischen@pcnet1.pcnet.com> Cc: Julian Elischer <julian@elischer.org> Subject: Re: libkse -> libpthreads Message-ID: <20030421190707.B76635-100000@mail.chesapeake.net> In-Reply-To: <Pine.GSO.4.10.10304211802560.20923-100000@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-threads
> To unsubscribe, send any mail to "freebsd-threads-unsubscribe@freebsd.org"
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030421190707.B76635-100000>