libkse -> libpthreads

Narvi narvi at haldjas.folklore.ee
Mon Apr 21 16:21:59 PDT 2003


On Mon, 21 Apr 2003, Daniel Eischen wrote:

> >
> > Solaris libthr is not a 1:1 thread library - the difference between
>
> Yes, I believe it now is.
>

If by "now" you mean Solaris 9, then yes, this is so. This is not a
fundamental issue, merely how kernel API-s are used. On Solaris 8 you get
both the "old" M:N version and the Solaris 9 style 1:1 version in
/usr/lib/lwp. There is no way to tell what it will be in Solaris 9+x for
some arbitrary positive value of x.

> > libpthread and libthread is that libthread implements UI (sometimes also
> > called Solaris) threads, and not pthreads.
>
> And libthr threads are sorta like native threads.
>

No. The 'native' threads are LWP-s and both libthread and libpthread are
implemented in terms of LWPs and related syscalls.

[snip]

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

If you are confident that a working libkse is available and that there
will not be a support nightmerte afterwards, then naturaly, my objections
to the naming scheme evaporate.

> --
> Dan Eischen
>




More information about the freebsd-threads mailing list