From owner-freebsd-current@FreeBSD.ORG Mon Mar 29 19:43:17 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3513B16A4CE for ; Mon, 29 Mar 2004 19:43:17 -0800 (PST) Received: from gw.celabo.org (gw.celabo.org [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9C2CD43D45 for ; Mon, 29 Mar 2004 19:43:16 -0800 (PST) (envelope-from nectar@celabo.org) Received: from madman.celabo.org (madman.celabo.org [10.0.1.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "madman.celabo.org", Issuer "celabo.org CA" (not verified)) by gw.celabo.org (Postfix) with ESMTP id 46C385485D; Mon, 29 Mar 2004 21:43:16 -0600 (CST) Received: by madman.celabo.org (Postfix, from userid 1001) id C85EA6D465; Mon, 29 Mar 2004 21:43:15 -0600 (CST) Date: Mon, 29 Mar 2004 21:43:15 -0600 From: "Jacques A. Vidrine" To: Daniel Eischen Message-ID: <20040330034315.GC5998@madman.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , Daniel Eischen , Sean McNeil , freebsd-current@FreeBSD.org References: <20040330023247.GA5637@madman.celabo.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.6i cc: freebsd-current@FreeBSD.org cc: Sean McNeil Subject: Re: nss_ldap broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2004 03:43:17 -0000 On Mon, Mar 29, 2004 at 10:31:56PM -0500, Daniel Eischen wrote: > On Mon, 29 Mar 2004, Jacques A. Vidrine wrote: > > > On Fri, Mar 26, 2004 at 05:51:02PM -0500, Daniel Eischen wrote: > > > I think I made a comment about how you should always > > > prefix _pthread_foo() calls with 'if (__isthreaded)'. > > > > Yes, I'm sure you did. My recollection was that it was an > > optimization only, but it seems either I misunderstood or my > > recollection is poor (or both) :-) > > I had no idea that libpthread would be loaded then unloaded. Me neither :-) > > (2) When a threading library is loaded (by any cause? DT_NEEDED? > > dlopen RTLD_GLOBAL? dlopen RTLD_LOCAL?), __isthreaded is set > > to 1 > > No, __isthreaded is only set to 1 (non-zero) when the first > thread (other than main) is created. But the library is > auto-initialized and that's when libc's jump table is > filled. Gotcha, thanks for the clarification. > > (3) When a threading library is unloaded, __isthreaded is reset to 0 > > No, once threaded always threaded. There's really no going > back. So e.g. dlopen(libpthread) ... dlclose(libpthread) is not supported? And following from that, dlopen(object_which_depends_on_libpthread) ... dlclose(object_which_depends_on_libpthread) may also not be supported? [...] > I'm unsure how nss_ldap was built to depend on libpthread (or > any threads library). I built it from ports and 'ldd' didn't > report any dependency on a threads library. Interesting. Rebuilt a few days ago after updating to OpenLDAP 2.1: % ldd /usr/local/lib/nss_ldap.so.1 /usr/local/lib/nss_ldap.so.1: libldap.so.2 => /usr/local/lib/libldap.so.2 (0x2815f000) liblber.so.2 => /usr/local/lib/liblber.so.2 (0x28189000) libpthread.so.1 => /usr/lib/libpthread.so.1 (0x28194000) libssl.so.3 => /usr/lib/libssl.so.3 (0x281b7000) libcrypto.so.3 => /lib/libcrypto.so.3 (0x281e4000) > An example of how to build a library that is thread-safe > but doesn't bring in the threads library is libgcc. It uses > weak references (not definitions, like you see in our libc > and libpthread) to the necessary locking functions and > pthread_create. For instance: > > #pragma weak pthread_create > #pragma weak pthread_mutex_lock > #pragma weak pthread_mutex_unlock > ... > > static void > foo(void) > { > ... > if (pthread_create != NULL) { > pthread_mutex_lock(&foo_lock); > ... > pthread_mutex_unlock(&foo_lock); > } > ... > } > > By making the pthread_* references weak, you don't need to be linked > to the threads library; they will be NULL if it is not present. > But if an application is linked to the threads library, then > those references won't be NULL. There may be a little more > fu to it, but that's the general idea. Huh. Can/Should something like this be hidden within , I wonder? Cheers, -- Jacques Vidrine / nectar@celabo.org / jvidrine@verio.net / nectar@freebsd.org