Date: Thu, 8 Jan 2004 00:46:42 -0500 (EST) From: Daniel Eischen <eischen@vigrid.com> To: Robert Watson <rwatson@freebsd.org> Cc: freebsd-threads@freebsd.org Subject: Re: Release criteria for libkse -> libpthread switch? Message-ID: <Pine.GSO.4.10.10401080024340.24649-100000@pcnet5.pcnet.com> In-Reply-To: <Pine.NEB.3.96L.1040107202520.13166C-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 7 Jan 2004, Robert Watson wrote: > > 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. Right, I think this is mostly solved by changing gcc -pthread to use -lpthread (at the same time as the libkse switchover) and changing the default PTHREAD_LIBS to -lpthread. That gets you most of the way there, but there may still be ports that know about the existence of libc_r and pick that up as well. I think we need a portbuild run to find possible offenders. Perhaps you could remove libc_r from the system during the run to force those ports to fail. > > > 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 > users. I think we resolved to keep -pthread and have it cause a link to -lc_r (and -lpthread after the switchover). I'd like to noop -pthread when linking shared libraries (so you can have application A use libc_r, application B use libpthread, and both applications use libGL.so) but that could be up for discussion. > > > (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...? The goal is to have gdb support for 5.3. > > > 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 :-). Other than debugging, sparc64 & alpha support, I think it already has more features than libc_r. Judging by the last reaction I got when -pthread was removed, I'd suggest we first try to see how the switchover is going to affect ports. Is Kris due back soon?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10401080024340.24649-100000>