From owner-freebsd-threads@FreeBSD.ORG Mon Nov 16 11:07:03 2009 Return-Path: Delivered-To: freebsd-threads@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1212C10656A3 for ; Mon, 16 Nov 2009 11:07:03 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id F3F908FC24 for ; Mon, 16 Nov 2009 11:07:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nAGB720f011314 for ; Mon, 16 Nov 2009 11:07:02 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nAGB725P011312 for freebsd-threads@FreeBSD.org; Mon, 16 Nov 2009 11:07:02 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 16 Nov 2009 11:07:02 GMT Message-Id: <200911161107.nAGB725P011312@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-threads@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-threads@FreeBSD.org X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 11:07:03 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o threa/136345 threads Recursive read rwlocks in thread A cause deadlock with o threa/135673 threads databases/mysql50-server - MySQL query lock-ups on 7.2 p threa/135462 threads [PATCH] _thread_cleanupspecific() doesn't handle delet o threa/133734 threads 32 bit libthr failing pthread_create() o threa/128922 threads threads hang with xorg running o threa/127225 threads bug in lib/libthr/thread/thr_init.c o threa/122923 threads 'nice' does not prevent background process from steali o threa/121336 threads lang/neko threading ok on UP, broken on SMP (FreeBSD 7 o threa/118715 threads kse problem o threa/116668 threads can no longer use jdk15 with libthr on -stable SMP o threa/116181 threads /dev/io-related io access permissions are not propagat o threa/115211 threads pthread_atfork misbehaves in initial thread o threa/110636 threads [request] gdb(1): using gdb with multi thread applicat o threa/110306 threads apache 2.0 segmentation violation when calling gethost o threa/103975 threads Implicit loading/unloading of libpthread.so may crash o threa/101323 threads [patch] fork(2) in threaded programs broken. s threa/100815 threads FBSD 5.5 broke nanosleep in libc_r s threa/94467 threads send(), sendto() and sendmsg() are not correct in libc s threa/84483 threads problems with devel/nspr and -lc_r on 4.x o threa/83914 threads [libc] popen() doesn't work in static threaded program o threa/80992 threads abort() sometimes not caught by gdb depending on threa o threa/80435 threads panic on high loads o threa/79887 threads [patch] freopen() isn't thread-safe o threa/79683 threads svctcp_create() fails if multiple threads call at the s threa/76694 threads fork cause hang in dup()/close() function in child (-l s threa/76690 threads fork hang in child for -lc_r o threa/75374 threads pthread_kill() ignores SA_SIGINFO flag o threa/75273 threads FBSD 5.3 libpthread (KSE) bug o threa/72953 threads fork() unblocks blocked signals w/o PTHREAD_SCOPE_SYST o threa/70975 threads [sysvipc] unexpected and unreliable behaviour when usi s threa/69020 threads pthreads library leaks _gc_mutex s threa/49087 threads Signals lost in programs linked with libc_r s threa/48856 threads Setting SIGCHLD to SIG_IGN still leaves zombies under s threa/40671 threads pthread_cancel doesn't remove thread from condition qu s threa/39922 threads [threads] [patch] Threaded applications executed with s threa/37676 threads libc_r: msgsnd(), msgrcv(), pread(), pwrite() need wra s threa/34536 threads accept() blocks other threads s threa/32295 threads [libc_r] [patch] pthread(3) dont dequeue signals s threa/30464 threads pthread mutex attributes -- pshared s threa/24632 threads libc_r delicate deviation from libc in handling SIGCHL s threa/24472 threads libc_r does not honor SO_SNDTIMEO/SO_RCVTIMEO socket o 41 problems total. From owner-freebsd-threads@FreeBSD.ORG Mon Nov 16 11:15:15 2009 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4FFC81065693 for ; Mon, 16 Nov 2009 11:15:15 +0000 (UTC) (envelope-from lujiandong1001@yahoo.com.cn) Received: from web15707.mail.cnb.yahoo.com (web15707.mail.cnb.yahoo.com [202.165.102.74]) by mx1.freebsd.org (Postfix) with SMTP id 6B0178FC22 for ; Mon, 16 Nov 2009 11:15:14 +0000 (UTC) Received: (qmail 96247 invoked by uid 60001); 16 Nov 2009 10:48:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.cn; s=s1024; t=1258368511; bh=WMUGvH9ZoP6BqivJiDybTH02dvoM0N3gEWWTllFUepc=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=rKOIQrub+gYwG4v71P9xHtSwlDDftTKheF/q0Pfz7YSDYqH57rjAcV8HePH7gAmXeDlev453l7OZcNIHWF1bgnQVuvgRYovlh5Voivt2vYl5Roe+rKBfeZMLu1C6dgN9n+AgXC0wwicuzffwKYVHHarXdagXyHDuBbZH0J9MDZ0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.cn; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=cPibdZMLg2NXd+850v+S13oP+UnNNZEA/vDuxOugs0DQxsSWixqMD0KZpmK/dQGZsUfDZXfH/+Du6/ZeLnvZyQGIfMvRMZU+WUpxqkbelLxqbsgPksP9pYvnJwHGtC1rAajyNJUTOH324xwROFwd5rm3+JfNKw8zeY9Ai96LIa0=; Message-ID: <885642.96228.qm@web15707.mail.cnb.yahoo.com> X-YMail-OSG: ltVF44QVM1kdNnIje8zum5Zl2yeULf6jJx9VRRqW4CcV7DZGaaolsiGkgYAepysNT41UrrTC04atBf6gznYo_EWM.k6N_wtix4FuMhbcbdvbT.gsIv2LL_cRSScC78S7Lmt6S8bSzwrMWDEElntrfVyPZ9KU5BeCrVi39zaBm_u9.2NCth2ryzshLLjHZTHTy1HN0UUfInwapo.PFyulCP0RO71yzuxhsFFvjHmnonQH8pCkGEuUPBg79fgpJxQ- Received: from [218.241.83.19] by web15707.mail.cnb.yahoo.com via HTTP; Mon, 16 Nov 2009 18:48:31 CST X-Mailer: YahooMailClassic/8.1.6 YahooMailWebService/0.7.361.4 Date: Mon, 16 Nov 2009 18:48:31 +0800 (CST) From: Jiandong Lu To: freebsd-threads@freebsd.org MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 16 Nov 2009 12:28:51 +0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: how to build libthr except other components of 'world' X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 11:15:15 -0000 Hi,everyone, =C2=A0=C2=A0=C2=A0 I checkout FreeBSD=E2=80=98s source codes to my /usr/src =C2=A0=C2=A0=C2=A0 I use command=20 =C2=A0=C2=A0=C2=A0 make buildworld=20 =C2=A0=C2=A0=C2=A0 int directory /usr/src to build a world.I want to do som= e debug to lib /usr/src/lib/libthr.If I modified some files in /usr/src/lib= /libthr/thread, how could I build libthr except other components of world? =C2=A0=C2=A0 btw,I execute command=20 =C2=A0=C2=A0 make =C2=A0=C2=A0 in /usr/src/lib/libthr get this : cc -O2 -fno-strict-aliasing -pipe=C2=A0 -DPTHREAD_KERNEL -I/usr/src/lib/lib= thr/../libc/include -I/usr/src/lib/libthr/thread=C2=A0 -I/usr/src/lib/libth= r/../../include -I/usr/src/lib/libthr/arch/i386/include -I/usr/src/lib/libt= hr/sys -I/usr/src/lib/libthr/../../libexec/rtld-elf -I/usr/src/lib/libthr/.= ./../libexec/rtld-elf/i386 -I/usr/src/lib/libthr/../libthread_db -Winline -= D_PTHREADS_INVARIANTS -DSYSCALL_COMPAT -Wsystem-headers -Wall -Wno-format-y= 2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpoin= ter-arith -Wno-uninitialized -Wno-pointer-sign -c /usr/src/lib/libthr/arch/= i386/i386/pthread_md.c In file included from /usr/src/lib/libthr/arch/i386/i386/pthread_md.c:33: /usr/src/lib/libthr/../../include/string.h:86: warning: no previous prototy= pe for 'strdup' /usr/src/lib/libthr/../../include/string.h: In function 'strdup': /usr/src/lib/libthr/../../include/string.h:86: error: expected declaration = specifiers before '__malloc_like' /usr/src/lib/libthr/../../include/string.h:96: warning: '__pure__' attribut= e ignored /usr/src/lib/libthr/../../include/string.h:101: warning: '__pure__' attribu= te ignored /usr/src/lib/libthr/../../include/string.h:104: error: expected '=3D', ',',= ';', 'asm' or '__attribute__' before '__malloc_like' /usr/src/lib/libthr/../../include/string.h:105: warning: '__pure__' attribu= te ignored /usr/src/lib/libthr/../../include/string.h:108: warning: '__pure__' attribu= te ignored /usr/src/lib/libthr/../../include/string.h:110: warning: '__pure__' attribu= te ignored /usr/src/lib/libthr/../../include/string.h:111: warning: '__pure__' attribu= te ignored /usr/src/lib/libthr/../../include/string.h:118: warning: '__pure__' attribu= te ignored /usr/src/lib/libthr/../../include/string.h:119: warning: '__pure__' attribu= te ignored In file included from /usr/src/lib/libthr/arch/i386/i386/pthread_md.c:34: /usr/src/lib/libthr/../../libexec/rtld-elf/rtld_tls.h:60: error: storage cl= ass specified for parameter '_rtld_allocate_tls' /usr/src/lib/libthr/../../libexec/rtld-elf/rtld_tls.h:67: error: storage cl= ass specified for parameter '_rtld_free_tls' In file included from /usr/src/lib/libthr/arch/i386/include/pthread_md.h:36= , =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 from /usr/src/lib/libthr/arch/i386/i386/pthread_md.c:= 36: /usr/src/lib/libthr/../../include/stddef.h:45: error: storage class specifi= ed for parameter 'ptrdiff_t' /usr/src/lib/libthr/../../include/stddef.h:49: error: storage class specifi= ed for parameter 'rune_t' /usr/src/lib/libthr/../../include/stddef.h:61: error: storage class specifi= ed for parameter 'wchar_t' In file included from /usr/src/lib/libthr/arch/i386/i386/pthread_md.c:36: /usr/src/lib/libthr/arch/i386/include/pthread_md.h:52: warning: empty decla= ration /usr/src/lib/libthr/arch/i386/include/pthread_md.h:88: error: expected '=3D= ', ',', ';', 'asm' or '__attribute__' before '{' token /usr/src/lib/libthr/arch/i386/include/pthread_md.h:95: error: expected '=3D= ', ',', ';', 'asm' or '__attribute__' before '{' token /usr/src/lib/libthr/arch/i386/include/pthread_md.h:102: error: expected '= =3D', ',', ';', 'asm' or '__attribute__' before '{' token /usr/src/lib/libthr/arch/i386/i386/pthread_md.c:40: error: expected '=3D', = ',', ';', 'asm' or '__attribute__' before '{' token /usr/src/lib/libthr/arch/i386/i386/pthread_md.c:54: error: expected '=3D', = ',', ';', 'asm' or '__attribute__' before '{' token /usr/src/lib/libthr/arch/i386/i386/pthread_md.c:57: error: old-style parame= ter declarations in prototyped function definition /usr/src/lib/libthr/../../include/string.h:86: error: parameter name omitte= d /usr/src/lib/libthr/arch/i386/i386/pthread_md.c:57: error: expected '{' at = end of input *** Error code 1 Stop in /usr/src/lib/libthr. ---------------------------------- thanks. =C2=A0=20 =0A=0A=0A ___________________________________________________________ = =0A =E5=A5=BD=E7=8E=A9=E8=B4=BA=E5=8D=A1=E7=AD=89=E4=BD=A0=E5=8F=91=EF=BC= =8C=E9=82=AE=E7=AE=B1=E8=B4=BA=E5=8D=A1=E5=85=A8=E6=96=B0=E4=B8=8A=E7=BA=BF= =EF=BC=81 =0Ahttp://card.mail.cn.yahoo.com/ From owner-freebsd-threads@FreeBSD.ORG Thu Nov 19 15:30:23 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 B3ECC106566B for ; Thu, 19 Nov 2009 15:30:22 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 8A0188FC16 for ; Thu, 19 Nov 2009 15:30:22 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 372AF46B49 for ; Thu, 19 Nov 2009 10:30:22 -0500 (EST) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 7A5228A020 for ; Thu, 19 Nov 2009 10:30:21 -0500 (EST) From: John Baldwin To: threads@FreeBSD.org Date: Thu, 19 Nov 2009 10:30:13 -0500 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200911191030.14151.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 19 Nov 2009 10:30:21 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Subject: Using pthread_once() in libc X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 15:30:23 -0000 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? -- John Baldwin 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 From owner-freebsd-threads@FreeBSD.ORG Thu Nov 19 17:02:39 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 B904F10656A6; Thu, 19 Nov 2009 17:02:39 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 7488F8FC08; Thu, 19 Nov 2009 17:02:39 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 2462246B35; Thu, 19 Nov 2009 12:02:39 -0500 (EST) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 6BB1A8A021; Thu, 19 Nov 2009 12:02:38 -0500 (EST) From: John Baldwin To: Daniel Eischen Date: Thu, 19 Nov 2009 12:02:30 -0500 User-Agent: KMail/1.9.7 References: <200911191030.14151.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200911191202.30738.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 19 Nov 2009 12:02:38 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx 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 List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 17:02:39 -0000 On Thursday 19 November 2009 11:48:54 am Daniel Eischen wrote: > 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? Hmm, the libc stub will never run the init routine. I would like to do something like this: Index: stdtime/localtime.c =================================================================== --- stdtime/localtime.c (revision 199529) +++ stdtime/localtime.c (working copy) @@ -235,9 +235,8 @@ static char lcl_TZname[TZ_STRLEN_MAX + 1]; static int lcl_is_set; -static int gmt_is_set; +static pthread_once_t gmt_once = PTHREAD_ONCE_INIT; static pthread_rwlock_t lcl_rwlock = PTHREAD_RWLOCK_INITIALIZER; -static pthread_mutex_t gmt_mutex = PTHREAD_MUTEX_INITIALIZER; char * tzname[2] = { wildabbr, @@ -1464,6 +1463,17 @@ return tmp; } +static void +gmt_init(void) +{ + +#ifdef ALL_STATE + gmtptr = (struct state *) malloc(sizeof *gmtptr); + if (gmtptr != NULL) +#endif /* defined ALL_STATE */ + gmtload(gmtptr); +} + /* ** gmtsub is to gmtime as localsub is to localtime. */ @@ -1476,16 +1486,7 @@ { register struct tm * result; - _MUTEX_LOCK(&gmt_mutex); - if (!gmt_is_set) { -#ifdef ALL_STATE - gmtptr = (struct state *) malloc(sizeof *gmtptr); - if (gmtptr != NULL) -#endif /* defined ALL_STATE */ - gmtload(gmtptr); - gmt_is_set = TRUE; - } - _MUTEX_UNLOCK(&gmt_mutex); + _pthread_once(&gmt_once, gmt_init); result = timesub(timep, offset, gmtptr, tmp); #ifdef TM_ZONE /* -- John Baldwin From owner-freebsd-threads@FreeBSD.ORG Thu Nov 19 17:06:45 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 07084106568D; Thu, 19 Nov 2009 17:06:45 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id B79578FC13; Thu, 19 Nov 2009 17:06:44 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 49CD746B03; Thu, 19 Nov 2009 12:06:44 -0500 (EST) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 422968A020; Thu, 19 Nov 2009 12:06:43 -0500 (EST) From: John Baldwin To: Daniel Eischen Date: Thu, 19 Nov 2009 12:06:40 -0500 User-Agent: KMail/1.9.7 References: <200911191030.14151.jhb@freebsd.org> <200911191202.30738.jhb@freebsd.org> In-Reply-To: <200911191202.30738.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200911191206.40934.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 19 Nov 2009 12:06:43 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx 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 List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 17:06:45 -0000 On Thursday 19 November 2009 12:02:30 pm John Baldwin wrote: > On Thursday 19 November 2009 11:48:54 am Daniel Eischen wrote: > > 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? > > Hmm, the libc stub will never run the init routine. I would like to do > something like this: Perhaps this would work to fix pthread_once: Index: gen/_pthread_stubs.c =================================================================== --- gen/_pthread_stubs.c (revision 199529) +++ gen/_pthread_stubs.c (working copy) @@ -51,6 +51,8 @@ static int stub_main(void); static void *stub_null(void); +static int stub_once(pthread_once_t *once_control, + void (*init_routine)(void)); static struct pthread *stub_self(void); static int stub_zero(void); static int stub_true(void); @@ -105,7 +107,7 @@ {PJT_DUAL_ENTRY(stub_zero)}, /* PJT_MUTEX_LOCK */ {PJT_DUAL_ENTRY(stub_zero)}, /* PJT_MUTEX_TRYLOCK */ {PJT_DUAL_ENTRY(stub_zero)}, /* PJT_MUTEX_UNLOCK */ - {PJT_DUAL_ENTRY(stub_zero)}, /* PJT_ONCE */ + {PJT_DUAL_ENTRY(stub_once)}, /* PJT_ONCE */ {PJT_DUAL_ENTRY(stub_zero)}, /* PJT_RWLOCK_DESTROY */ {PJT_DUAL_ENTRY(stub_zero)}, /* PJT_RWLOCK_INIT */ {PJT_DUAL_ENTRY(stub_zero)}, /* PJT_RWLOCK_RDLOCK */ @@ -301,3 +303,14 @@ { exit(0); } + +static int +stub_once(pthread_once_t *once_control, void (*init_routine)(void)) +{ + + if (once_control->state == ONCE_DONE) + return (0); + init_routine(); + once_control->state = ONCE_DONE; + return (0); +} -- John Baldwin From owner-freebsd-threads@FreeBSD.ORG Thu Nov 19 17:09:35 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 56AD21065670; Thu, 19 Nov 2009 17:09:35 +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 F1D548FC18; Thu, 19 Nov 2009 17:09:34 +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 nAJH9XYw021276; Thu, 19 Nov 2009 12:09:33 -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 12:09:33 -0500 (EST) Date: Thu, 19 Nov 2009 12:09:33 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: John Baldwin In-Reply-To: <200911191202.30738.jhb@freebsd.org> Message-ID: References: <200911191030.14151.jhb@freebsd.org> <200911191202.30738.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 17:09:35 -0000 On Thu, 19 Nov 2009, John Baldwin wrote: > On Thursday 19 November 2009 11:48:54 am Daniel Eischen wrote: >> 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? > > Hmm, the libc stub will never run the init routine. I would like to do > something like this: Well, I suppose you could do that. But what happens if libthr gets dlopen()'d and your once function needs to initialize a mutex or something that can only be properly done by a real threads library? Can we envision a scenario where that would be a problem? -- DE From owner-freebsd-threads@FreeBSD.ORG Thu Nov 19 17:11:14 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 E45EE106566C; Thu, 19 Nov 2009 17:11:14 +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 841B28FC16; Thu, 19 Nov 2009 17:11:14 +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 nAJHBDDW022213; Thu, 19 Nov 2009 12:11:13 -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 12:11:13 -0500 (EST) Date: Thu, 19 Nov 2009 12:11:13 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: John Baldwin In-Reply-To: <200911191206.40934.jhb@freebsd.org> Message-ID: References: <200911191030.14151.jhb@freebsd.org> <200911191202.30738.jhb@freebsd.org> <200911191206.40934.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 17:11:15 -0000 On Thu, 19 Nov 2009, John Baldwin wrote: > On Thursday 19 November 2009 12:02:30 pm John Baldwin wrote: >> On Thursday 19 November 2009 11:48:54 am Daniel Eischen wrote: >>> 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? >> >> Hmm, the libc stub will never run the init routine. I would like to do >> something like this: > > Perhaps this would work to fix pthread_once: No objection here. Still trying to figure out if that could potentially cause a problem with a dlopen()'d libthr. -- DE From owner-freebsd-threads@FreeBSD.ORG Thu Nov 19 17:55:03 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 D9420106566B; Thu, 19 Nov 2009 17:55:02 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id A7F178FC14; Thu, 19 Nov 2009 17:55:02 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 319BF46B51; Thu, 19 Nov 2009 12:55:02 -0500 (EST) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 624A38A020; Thu, 19 Nov 2009 12:55:01 -0500 (EST) From: John Baldwin To: Daniel Eischen Date: Thu, 19 Nov 2009 12:54:50 -0500 User-Agent: KMail/1.9.7 References: <200911191030.14151.jhb@freebsd.org> <200911191202.30738.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200911191254.50902.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 19 Nov 2009 12:55:01 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx 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 List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 17:55:03 -0000 On Thursday 19 November 2009 12:09:33 pm Daniel Eischen wrote: > On Thu, 19 Nov 2009, John Baldwin wrote: > > > On Thursday 19 November 2009 11:48:54 am Daniel Eischen wrote: > >> 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? > > > > Hmm, the libc stub will never run the init routine. I would like to do > > something like this: > > Well, I suppose you could do that. But what happens if libthr gets > dlopen()'d and your once function needs to initialize a mutex or > something that can only be properly done by a real threads library? > Can we envision a scenario where that would be a problem? Hmmm, so I guess __is_threaded is how the dlopen() case is handled now for mutex lock/unlock as that avoids resolving the symbol until pthread_create() has been invoked? I guess then we could take an approach that works something like this: /* libc-internal function */ int _once(pthread_once_t *once_control, void (*init_routine)(void)) { if (__is_threaded) return (_pthread_once(once_control, init_routine)); return (_stub_once(once_control, init_routine)); } It is probably still a good idea to have the stub_once() patch I think so that pthread_once() DTRT in a single-threaded program. -- John Baldwin From owner-freebsd-threads@FreeBSD.ORG Thu Nov 19 20:00:21 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 1A62C10656A5; Thu, 19 Nov 2009 20:00:21 +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 B1E148FC13; Thu, 19 Nov 2009 20:00:20 +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 nAJK0JDd026688; Thu, 19 Nov 2009 15:00:19 -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 15:00:19 -0500 (EST) Date: Thu, 19 Nov 2009 15:00:19 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: John Baldwin In-Reply-To: <200911191254.50902.jhb@freebsd.org> Message-ID: References: <200911191030.14151.jhb@freebsd.org> <200911191202.30738.jhb@freebsd.org> <200911191254.50902.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 20:00:21 -0000 On Thu, 19 Nov 2009, John Baldwin wrote: > On Thursday 19 November 2009 12:09:33 pm Daniel Eischen wrote: >> On Thu, 19 Nov 2009, John Baldwin wrote: >> >>> On Thursday 19 November 2009 11:48:54 am Daniel Eischen wrote: >>>> 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? >>> >>> Hmm, the libc stub will never run the init routine. I would like to do >>> something like this: >> >> Well, I suppose you could do that. But what happens if libthr gets >> dlopen()'d and your once function needs to initialize a mutex or >> something that can only be properly done by a real threads library? >> Can we envision a scenario where that would be a problem? > > Hmmm, so I guess __is_threaded is how the dlopen() case is handled now for > mutex lock/unlock as that avoids resolving the symbol until pthread_create() > has been invoked? I guess then we could take an approach that works > something like this: > > /* libc-internal function */ > int > _once(pthread_once_t *once_control, void (*init_routine)(void)) > { > > if (__is_threaded) > return (_pthread_once(once_control, init_routine)); > > return (_stub_once(once_control, init_routine)); > } > > It is probably still a good idea to have the stub_once() patch I think so > that pthread_once() DTRT in a single-threaded program. I guess that works. -- DE From owner-freebsd-threads@FreeBSD.ORG Thu Nov 19 20:39:54 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 143611065679; Thu, 19 Nov 2009 20:39:54 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id C33A88FC14; Thu, 19 Nov 2009 20:39:53 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 717AA46B51; Thu, 19 Nov 2009 15:39:53 -0500 (EST) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id B15BA8A020; Thu, 19 Nov 2009 15:39:52 -0500 (EST) From: John Baldwin To: Daniel Eischen Date: Thu, 19 Nov 2009 15:39:47 -0500 User-Agent: KMail/1.9.7 References: <200911191030.14151.jhb@freebsd.org> <200911191254.50902.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_T0aBLpbb6zyZ750" Message-Id: <200911191539.47588.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 19 Nov 2009 15:39:52 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx 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 List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 20:39:54 -0000 --Boundary-00=_T0aBLpbb6zyZ750 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Thursday 19 November 2009 3:00:19 pm Daniel Eischen wrote: > On Thu, 19 Nov 2009, John Baldwin wrote: > > > On Thursday 19 November 2009 12:09:33 pm Daniel Eischen wrote: > >> On Thu, 19 Nov 2009, John Baldwin wrote: > >> > >>> On Thursday 19 November 2009 11:48:54 am Daniel Eischen wrote: > >>>> 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? > >>> > >>> Hmm, the libc stub will never run the init routine. I would like to do > >>> something like this: > >> > >> Well, I suppose you could do that. But what happens if libthr gets > >> dlopen()'d and your once function needs to initialize a mutex or > >> something that can only be properly done by a real threads library? > >> Can we envision a scenario where that would be a problem? > > > > Hmmm, so I guess __is_threaded is how the dlopen() case is handled now for > > mutex lock/unlock as that avoids resolving the symbol until pthread_create() > > has been invoked? I guess then we could take an approach that works > > something like this: > > > > /* libc-internal function */ > > int > > _once(pthread_once_t *once_control, void (*init_routine)(void)) > > { > > > > if (__is_threaded) > > return (_pthread_once(once_control, init_routine)); > > > > return (_stub_once(once_control, init_routine)); > > } > > > > It is probably still a good idea to have the stub_once() patch I think so > > that pthread_once() DTRT in a single-threaded program. > > I guess that works. Ok, after a few rounds with the compiler the attached patch actually finished a buildworld. Do you have any feedback on it? -- John Baldwin --Boundary-00=_T0aBLpbb6zyZ750 Content-Type: text/x-diff; charset="iso-8859-1"; name="stdtime.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="stdtime.patch" Index: gen/Makefile.inc =================================================================== --- gen/Makefile.inc (revision 199529) +++ gen/Makefile.inc (working copy) @@ -5,7 +5,7 @@ .PATH: ${.CURDIR}/${MACHINE_ARCH}/gen ${.CURDIR}/gen SRCS+= __getosreldate.c __xuname.c \ - _pthread_stubs.c _rand48.c _spinlock_stub.c _thread_init.c \ + _once_stub.c _pthread_stubs.c _rand48.c _spinlock_stub.c _thread_init.c \ alarm.c arc4random.c assert.c basename.c check_utility_compat.c \ clock.c closedir.c confstr.c \ crypt.c ctermid.c daemon.c devname.c dirname.c disklabel.c \ Index: gen/_once_stub.c =================================================================== --- gen/_once_stub.c (revision 0) +++ gen/_once_stub.c (revision 0) @@ -0,0 +1,44 @@ +/*- + * XXX: Copyright + */ + +#include +__FBSDID("$FreeBSD$"); + +#include "namespace.h" +#include +#include "un-namespace.h" +#include "libc_private.h" + +/* + * This implements pthread_once() for the single-threaded case. It is + * non-static so that it can be used by _pthread_stubs.c. + */ +int +_libc_once(pthread_once_t *once_control, void (*init_routine)(void)) +{ + + if (once_control->state == PTHREAD_NEEDS_INIT) + return (0); + init_routine(); + once_control->state = PTHREAD_DONE_INIT; + return (0); +} + +/* + * This is the internal interface provided to libc. It will use + * pthread_once() from the threading library in a multi-threaded + * process and _libc_once() for a single-threaded library. Because + * _libc_once() uses the same ABI for the values in the pthread_once_t + * structure as the threading library, it is safe for a process to + * switch from _libc_once() to pthread_once() when threading is + * enabled. + */ +int +_once(pthread_once_t *once_control, void (*init_routine)(void)) +{ + + if (__isthreaded) + return (_pthread_once(once_control, init_routine)); + return (_libc_once(once_control, init_routine)); +} Property changes on: gen/_once_stub.c ___________________________________________________________________ Added: svn:mime-type + text/plain Added: svn:keywords + FreeBSD=%H Added: svn:eol-style + native Index: gen/_pthread_stubs.c =================================================================== --- gen/_pthread_stubs.c (revision 199529) +++ gen/_pthread_stubs.c (working copy) @@ -105,7 +105,7 @@ {PJT_DUAL_ENTRY(stub_zero)}, /* PJT_MUTEX_LOCK */ {PJT_DUAL_ENTRY(stub_zero)}, /* PJT_MUTEX_TRYLOCK */ {PJT_DUAL_ENTRY(stub_zero)}, /* PJT_MUTEX_UNLOCK */ - {PJT_DUAL_ENTRY(stub_zero)}, /* PJT_ONCE */ + {PJT_DUAL_ENTRY(_libc_once)}, /* PJT_ONCE */ {PJT_DUAL_ENTRY(stub_zero)}, /* PJT_RWLOCK_DESTROY */ {PJT_DUAL_ENTRY(stub_zero)}, /* PJT_RWLOCK_INIT */ {PJT_DUAL_ENTRY(stub_zero)}, /* PJT_RWLOCK_RDLOCK */ Index: stdtime/localtime.c =================================================================== --- stdtime/localtime.c (revision 199529) +++ stdtime/localtime.c (working copy) @@ -235,9 +235,8 @@ static char lcl_TZname[TZ_STRLEN_MAX + 1]; static int lcl_is_set; -static int gmt_is_set; +static pthread_once_t gmt_once = PTHREAD_ONCE_INIT; static pthread_rwlock_t lcl_rwlock = PTHREAD_RWLOCK_INITIALIZER; -static pthread_mutex_t gmt_mutex = PTHREAD_MUTEX_INITIALIZER; char * tzname[2] = { wildabbr, @@ -1464,6 +1463,17 @@ return tmp; } +static void +gmt_init(void) +{ + +#ifdef ALL_STATE + gmtptr = (struct state *) malloc(sizeof *gmtptr); + if (gmtptr != NULL) +#endif /* defined ALL_STATE */ + gmtload(gmtptr); +} + /* ** gmtsub is to gmtime as localsub is to localtime. */ @@ -1476,16 +1486,7 @@ { register struct tm * result; - _MUTEX_LOCK(&gmt_mutex); - if (!gmt_is_set) { -#ifdef ALL_STATE - gmtptr = (struct state *) malloc(sizeof *gmtptr); - if (gmtptr != NULL) -#endif /* defined ALL_STATE */ - gmtload(gmtptr); - gmt_is_set = TRUE; - } - _MUTEX_UNLOCK(&gmt_mutex); + _once(&gmt_once, gmt_init); result = timesub(timep, offset, gmtptr, tmp); #ifdef TM_ZONE /* Index: include/libc_private.h =================================================================== --- include/libc_private.h (revision 199529) +++ include/libc_private.h (working copy) @@ -34,6 +34,7 @@ #ifndef _LIBC_PRIVATE_H_ #define _LIBC_PRIVATE_H_ +#include /* * This global flag is non-zero when a process has created one @@ -147,6 +148,13 @@ void _init_tls(void); /* + * Provides pthread_once()-like functionality for both single-threaded and + * multithreaded applications. + */ +int _once(pthread_once_t *, void (*)(void)); +int _libc_once(pthread_once_t *, void (*)(void)); + +/* * Set the TLS thread pointer */ void _set_tp(void *tp); --Boundary-00=_T0aBLpbb6zyZ750-- From owner-freebsd-threads@FreeBSD.ORG Thu Nov 19 21:02:08 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 5A8F51065670; Thu, 19 Nov 2009 21:02:08 +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 153708FC12; Thu, 19 Nov 2009 21:02:07 +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 nAJL26oC028862; Thu, 19 Nov 2009 16:02:06 -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 16:02:06 -0500 (EST) Date: Thu, 19 Nov 2009 16:02:06 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: John Baldwin In-Reply-To: <200911191539.47588.jhb@freebsd.org> Message-ID: References: <200911191030.14151.jhb@freebsd.org> <200911191254.50902.jhb@freebsd.org> <200911191539.47588.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Content-ID: Content-Disposition: inline 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 21:02:08 -0000 On Thu, 19 Nov 2009, John Baldwin wrote: > On Thursday 19 November 2009 3:00:19 pm Daniel Eischen wrote: >> >> I guess that works. > > Ok, after a few rounds with the compiler the attached patch actually finished > a buildworld. Do you have any feedback on it? That looks fine to me :-) -- DE