libkse -> libpthreads

[Terry Lambert]

Narvi wrote:
> Solaris libthr is not a 1:1 thread library - the difference between
> libpthread and libthread is that libthread implements UI (sometimes also
> called Solaris) threads, and not pthreads.

And back in SunOS 4.1.3_U2 days, and carried forward for binary
compatability for a while, there was a "liblwp", which was a user
space call conversion threads library, very much like our modern
FreeBSD libc_r.  Everything old is new again... 8-).


> > 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.
> 
> At least for the moment it is not clear that one of teh libraries is a
> winner and will eliminate the other, 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

FWIW:

My post earlier, and Daniel's response, were meant to highlight
the fact that there are, in fact, only different tradeoffs at
this point because the libkse gets an upcall on block and calls
kse_release() in the 1:1 case, but otherwise has identical function
as libthr (no other tradeoffs).  The upcalls and the kse_release(),
as well as UTS entry, could be (and are intended to be) eliminated
in the PTHREAD_SCOPE_SYSTEM case.

After that, there are *NO* implementation tradeoffs between the two;
libkse is a complete superset of libthr.

The only real difference, after that, is that the signals in libthr
are questionable (i.e. they have been questioned but not answered
to everyone's satisfaction), and that it's impossible for libthr to
implement the proper POSIX compliant semantics for PTHREAD_SCOPE_PROCESS.

It's really important for people to understand both implementations
well enough to be able to comment on them, before claiming differences
that are really not there.

-- Terry