From owner-freebsd-threads@FreeBSD.ORG Thu Nov 19 16:48:56 2009 Return-Path: Delivered-To: threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8AB261065672; Thu, 19 Nov 2009 16:48:56 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 4D1DC8FC13; Thu, 19 Nov 2009 16:48:55 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.3/8.14.3/NETPLEX) with ESMTP id nAJGmsXw008855; Thu, 19 Nov 2009 11:48:54 -0500 (EST) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.2.2 (mail.netplex.net [204.213.176.10]); Thu, 19 Nov 2009 11:48:54 -0500 (EST) Date: Thu, 19 Nov 2009 11:48:54 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: John Baldwin In-Reply-To: <200911191030.14151.jhb@freebsd.org> Message-ID: References: <200911191030.14151.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: threads@freebsd.org Subject: Re: Using pthread_once() in libc X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 16:48:56 -0000 On Thu, 19 Nov 2009, John Baldwin wrote: > I would like to provide a pthread_once()-like facility in libc that library > bits can use to initialize data safely rather than trying to home-roll their > own variants (see the recent commit to stdtime in libc). Ideally what I > would like to do is have libc use the "real" pthread_once() when libthr is > linked in and fall back to a simple stub without libthr linked in. I know we > already do something like this for _spinlock() and friends. My question is > what is the most correct way to do this? Should libc grow a new _once() > symbol ala _spinlock() that is a weak symbol to a stub version and > pthread_once() in thr_once.c would override that, or should there be a > _pthread_once() in libc that is a stub in place of the current stub_zero? I > noticed a comment in thr_spinlock.c saying the spinlock stuff is kept for > backwards compat. Does this mean that for the future we would like to expose > pthread symbols directly in libc? Meaning would we rather have libc export a > pthread_once() and that ideally libc would be using pthread_mutex_lock/unlock > instead of _spinlock/unlock? pthread_once() is already a stub in libc that gets overloaded with the real thing when libthr is linked. See libc/gen/_pthread_stubs.c. Isn't that what you want or does it not serve your purpose? I think as soon as we get pthread lock types (at least mutex, cv's, and semaphores) implemented as structs instead of opaque pointers, then we can do away with the spinlocks. Currently, the library knows that spinlocks are different and plays games to avoid allocation problems at startup. At least that's my recollection. -- DE