Date: Wed, 7 Jan 2004 20:39:30 -0500 (EST) From: Robert Watson <rwatson@freebsd.org> To: Craig Rodrigues <rodrigc@crodrigues.org> Cc: freebsd-threads@freebsd.org Subject: Re: Release criteria for libkse -> libpthread switch? Message-ID: <Pine.NEB.3.96L.1040107202520.13166C-100000@fledge.watson.org> In-Reply-To: <20040108012007.GA38122@crodrigues.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 users. > > (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@fledge.watson.org Senior Research Scientist, McAfee Research
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1040107202520.13166C-100000>