Release criteria for libkse -> libpthread switch?

Robert Watson rwatson at
Wed Jan 7 17:41:02 PST 2004

On Wed, 7 Jan 2004, Craig Rodrigues wrote:

> > other than that the issue probably got addressed too late in the 5.2
> > release process.  
> Well 5.2 has branched, and let's assume that it will be released shortly
> after the appropriate QA and bugfixing.  Are there any issues that would
> prevent moving to KSE as the default on -current at this very moment,
> since 5.2 is on its own branch? 

Agreed.  I think the waiting was to prevent 5-CURRENT from diverging too
much from 5.2 before 5.2 is actually out, but I think now would be a fine
time to do it if the other dependencies are met.

> > There are a number of running concerns, including: 
> > 
> > (1) Avoid building a binary library name dependency into all the pre-built
> >     packages we distribute. 
> Can you explain this?  I don't fully understand. 

When we build packages, etc, that rely on threading, a library name is
built into each binary and library depending on it identifying the
dependency.  Currently, the packages built in the package cluster use
"libc_r" as the name to depend on for threads.  I think the right
long-term answer is for thread-dependent packages to simply link against
"libpthread".  People can rebuild locally to use something else, rename
libraries, or use libmap.conf to select alternatives.  What I don't want
to see happen is lots of binaries and libraries with conflicting
dependencies, and I want to avoid a lot of applications linking against a
name that will go away, be insufficiently supported, etc. 

> > Also, resolve any lasting concerns about how
> >     build processes should say "And I want threads, dammit".
> This seems to be a point of debate, but it would be nice to resolve
> this sooner rather than later.  My opinion is to do the following:
> - move libkse to libpthread
> - inform users that they must use -lpthread link in thread support
> - remove -pthread in gcc (maybe deprecate it instead)
> - fix the ports appropriately with PTHREAD_CFLAGS and PTHREAD_LDFLAGS 

There seems to be continuing disagreement on the gcc -pthread thing; I
don't really have much of an opinion on it, except that I think we should
choose the path of least headache.  And that I suspect that path is to
keep it around...  The one nice thing about dropping -pthread is it will
force everyone to go out and update the ports, but that sounds like a
technical solution to a social problem.  We could as easily take other
paths visible only to ports developers in the cluster and shoot fewer

> > (2) Have services like process debugging, profiling available and known
> >     fully functional (or close). 
> This stuff is good to have, but should the lack of it prevent moving
> libkse -> libpthread?  It sounds like a lot of work.

Well, it means that we have to document, loudly and carefully somewhere,
that in the default configuration, gdb on threaded applications is no
longer supported...? 

> > us are running KSE as our libc_r via libmap.conf on all our machines, and
> > have been for many months, and it appears to hold up quite well :-).
> > Resolving how best to declare threading support in binaries will also
> > facilitate shipping the JDK linked against KSE.
> I also use libkse via libmap.conf, and am happy with it.  I also agree
> that having a KSE-friendly version of the JDK will be very important.
> Are there any other ports that we should focus our efforts on in getting
> KSE to work with?  httpd, mysql, ACE,....? 

That looks like a good starting list :-).  Apache2 + eviljava + mysql
sounds like a killer combination with kse.

My leaning is we should throw the switch to libkse sooner rather than
later to improve exposure, even though it's not quite feature complete. 
It was basically an accident of timing and intent that we didn't get to
the rename before 5.2.  For one thing, it will get applications to start
linking against libpthread sooner.  However, if we're going to throw the
switch, it would be good to know the features aren't far behind :-). 

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert at      Senior Research Scientist, McAfee Research

More information about the freebsd-threads mailing list