From owner-freebsd-threads@FreeBSD.ORG Wed Jan 7 21:46:46 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CAC4616A4CE; Wed, 7 Jan 2004 21:46:46 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id A0D6343D41; Wed, 7 Jan 2004 21:46:44 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i085kgiw001046; Thu, 8 Jan 2004 00:46:42 -0500 (EST) Date: Thu, 8 Jan 2004 00:46:42 -0500 (EST) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Robert Watson In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: Release criteria for libkse -> libpthread switch? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2004 05:46:46 -0000 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?