From owner-freebsd-threads@FreeBSD.ORG Mon May 26 11:06:57 2008 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 1CDE1106566B for ; Mon, 26 May 2008 11:06:57 +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 0871D8FC51 for ; Mon, 26 May 2008 11:06:57 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m4QB6uZN065067 for ; Mon, 26 May 2008 11:06:56 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m4QB6umc065063 for freebsd-threads@FreeBSD.org; Mon, 26 May 2008 11:06:56 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 26 May 2008 11:06:56 GMT Message-Id: <200805261106.m4QB6umc065063@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, 26 May 2008 11:06:57 -0000 Current FreeBSD problem reports Critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- s threa/76690 threads fork hang in child for -lc_r 1 problem total. Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- s threa/24472 threads libc_r does not honor SO_SNDTIMEO/SO_RCVTIMEO socket o s threa/24632 threads libc_r delicate deviation from libc in handling SIGCHL s bin/32295 threads pthread(3) dont dequeue signals s threa/34536 threads accept() blocks other threads s threa/39922 threads [threads] [patch] Threaded applications executed with s threa/48856 threads Setting SIGCHLD to SIG_IGN still leaves zombies under s threa/49087 threads Signals lost in programs linked with libc_r o threa/70975 threads [sysvipc] unexpected and unreliable behaviour when usi o threa/72953 threads fork() unblocks blocked signals w/o PTHREAD_SCOPE_SYST o threa/75273 threads FBSD 5.3 libpthread (KSE) bug o threa/75374 threads pthread_kill() ignores SA_SIGINFO flag s threa/76694 threads fork cause hang in dup()/close() function in child (-l o threa/79683 threads svctcp_create() fails if multiple threads call at the o threa/80435 threads panic on high loads o threa/83914 threads [libc] popen() doesn't work in static threaded program s threa/84483 threads problems with devel/nspr and -lc_r on 4.x s threa/94467 threads send(), sendto() and sendmsg() are not correct in libc s threa/100815 threads FBSD 5.5 broke nanosleep in libc_r o threa/101323 threads fork(2) in threaded programs broken. o threa/103975 threads Implicit loading/unloading of libpthread.so may crash o threa/110636 threads [request] gdb(1): using gdb with multi thread applicat o threa/118715 threads kse problem o threa/121336 threads lang/neko threading ok on UP, broken on SMP (FreeBSD 7 23 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- s threa/30464 threads pthread mutex attributes -- pshared s threa/37676 threads libc_r: msgsnd(), msgrcv(), pread(), pwrite() need wra s threa/40671 threads pthread_cancel doesn't remove thread from condition qu s threa/69020 threads pthreads library leaks _gc_mutex o threa/79887 threads [patch] freopen() isn't thread-safe o threa/80992 threads abort() sometimes not caught by gdb depending on threa o threa/110306 threads apache 2.0 segmentation violation when calling gethost o threa/115211 threads pthread_atfork misbehaves in initial thread o threa/116181 threads /dev/io-related io access permissions are not propagat o threa/116668 threads can no longer use jdk15 with libthr on -stable SMP o threa/122923 threads 'nice' does not prevent background process from steali 11 problems total. From owner-freebsd-threads@FreeBSD.ORG Fri May 30 06:40:36 2008 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 B400F1065672 for ; Fri, 30 May 2008 06:40:36 +0000 (UTC) (envelope-from davidxu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 7DF0A8FC1C for ; Fri, 30 May 2008 06:40:36 +0000 (UTC) (envelope-from davidxu@freebsd.org) Received: from apple.my.domain (root@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m4U6eXU6099548 for ; Fri, 30 May 2008 06:40:35 GMT (envelope-from davidxu@freebsd.org) Message-ID: <483FA1C0.2010506@freebsd.org> Date: Fri, 30 May 2008 14:42:08 +0800 From: David Xu User-Agent: Thunderbird 2.0.0.9 (X11/20071211) MIME-Version: 1.0 To: freebsd-threads@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: pthread_cleanup_push as a macro 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: Fri, 30 May 2008 06:40:36 -0000 I would like to make pthread_cleanup_push and pthread_cleanup_pop as a pair of macros, the current implementation has to malloc() and free() a pthread_cleanup memory block everytime, this is slow, the new one simply uses stack space, note that other OSes have already done it in this way. The patch keeps old functions and should not have binary compatible problem. http://people.freebsd.org/~davidxu/patch/pthread_cleanup_push.patch David Xu From owner-freebsd-threads@FreeBSD.ORG Fri May 30 18:41:41 2008 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 D5B311065672; Fri, 30 May 2008 18:41:41 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id DFFE78FC1C; Fri, 30 May 2008 18:41:41 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 8612F1A4D81; Fri, 30 May 2008 11:41:41 -0700 (PDT) Date: Fri, 30 May 2008 11:41:41 -0700 From: Alfred Perlstein To: David Xu Message-ID: <20080530184141.GG48790@elvis.mu.org> References: <483FA1C0.2010506@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <483FA1C0.2010506@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-threads@freebsd.org Subject: Re: pthread_cleanup_push as a macro 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: Fri, 30 May 2008 18:41:41 -0000 * David Xu [080529 23:40] wrote: > I would like to make pthread_cleanup_push and pthread_cleanup_pop as a > pair of macros, the current implementation has to malloc() and free() a > pthread_cleanup memory block everytime, this is slow, the new one > simply uses stack space, note that other OSes have already done it in > this way. The patch keeps old functions and should not have binary > compatible problem. > > http://people.freebsd.org/~davidxu/patch/pthread_cleanup_push.patch Heh, when I had to use QNX on a project this totally confused me, but if others are doing it then go for it. Does Solaris do it? -Alfred From owner-freebsd-threads@FreeBSD.ORG Fri May 30 21:48:45 2008 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 A5BD4106566C; Fri, 30 May 2008 21:48:45 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 61B1D8FC22; Fri, 30 May 2008 21:48:45 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m4ULmX9V027000; Fri, 30 May 2008 17:48:39 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-threads@FreeBSD.org Date: Fri, 30 May 2008 17:48:29 -0400 User-Agent: KMail/1.9.7 References: <483FA1C0.2010506@freebsd.org> In-Reply-To: <483FA1C0.2010506@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200805301748.29689.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Fri, 30 May 2008 17:48:39 -0400 (EDT) X-Virus-Scanned: ClamAV 0.91.2/7298/Fri May 30 15:28:07 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: David Xu Subject: Re: pthread_cleanup_push as a macro 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: Fri, 30 May 2008 21:48:45 -0000 On Friday 30 May 2008 02:42:08 am David Xu wrote: > I would like to make pthread_cleanup_push and pthread_cleanup_pop as a > pair of macros, the current implementation has to malloc() and free() a > pthread_cleanup memory block everytime, this is slow, the new one > simply uses stack space, note that other OSes have already done it in > this way. The patch keeps old functions and should not have binary > compatible problem. > > http://people.freebsd.org/~davidxu/patch/pthread_cleanup_push.patch Please do! -- John Baldwin From owner-freebsd-threads@FreeBSD.ORG Fri May 30 23:05:50 2008 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 0B95F1065671; Fri, 30 May 2008 23:05:50 +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 D82708FC13; Fri, 30 May 2008 23:05:49 +0000 (UTC) (envelope-from deischen@freebsd.org) 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 m4UN5mrA016822; Fri, 30 May 2008 19:05:48 -0400 (EDT) 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.0 (mail.netplex.net [204.213.176.10]); Fri, 30 May 2008 19:05:48 -0400 (EDT) Date: Fri, 30 May 2008 19:05:48 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: John Baldwin In-Reply-To: <200805301748.29689.jhb@freebsd.org> Message-ID: References: <483FA1C0.2010506@freebsd.org> <200805301748.29689.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: David Xu , freebsd-threads@freebsd.org Subject: Re: pthread_cleanup_push as a macro 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: Fri, 30 May 2008 23:05:50 -0000 On Fri, 30 May 2008, John Baldwin wrote: > On Friday 30 May 2008 02:42:08 am David Xu wrote: >> I would like to make pthread_cleanup_push and pthread_cleanup_pop as a >> pair of macros, the current implementation has to malloc() and free() a >> pthread_cleanup memory block everytime, this is slow, the new one >> simply uses stack space, note that other OSes have already done it in >> this way. The patch keeps old functions and should not have binary >> compatible problem. >> >> http://people.freebsd.org/~davidxu/patch/pthread_cleanup_push.patch > > Please do! I agree - Solaris does this too. I am unsure why you really need a strong_reference - I would prefer something that doesn't require it. -- DE From owner-freebsd-threads@FreeBSD.ORG Fri May 30 23:27:00 2008 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from alona.my.domain (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id D321E106567D; Fri, 30 May 2008 23:26:59 +0000 (UTC) (envelope-from davidxu@freebsd.org) Message-ID: <48408D5E.2010609@freebsd.org> Date: Sat, 31 May 2008 07:27:26 +0800 From: David Xu User-Agent: Thunderbird 2.0.0.9 (X11/20080323) MIME-Version: 1.0 To: Daniel Eischen References: <483FA1C0.2010506@freebsd.org> <200805301748.29689.jhb@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-threads@freebsd.org Subject: Re: pthread_cleanup_push as a macro 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: Fri, 30 May 2008 23:27:00 -0000 Daniel Eischen wrote: > On Fri, 30 May 2008, John Baldwin wrote: > >> On Friday 30 May 2008 02:42:08 am David Xu wrote: >>> I would like to make pthread_cleanup_push and pthread_cleanup_pop as a >>> pair of macros, the current implementation has to malloc() and free() a >>> pthread_cleanup memory block everytime, this is slow, the new one >>> simply uses stack space, note that other OSes have already done it in >>> this way. The patch keeps old functions and should not have binary >>> compatible problem. >>> >>> http://people.freebsd.org/~davidxu/patch/pthread_cleanup_push.patch >> >> Please do! > > I agree - Solaris does this too. I am unsure why you really need > a strong_reference - I would prefer something that doesn't require > it. > This becauses original _pthread_cleanup_push and _pthread_cleanup_pop are functions but not weak aliases, it is to keep compatibility. From owner-freebsd-threads@FreeBSD.ORG Sat May 31 01:49:33 2008 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 952121065724; Sat, 31 May 2008 01:49:33 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 32A3F8FC12; Sat, 31 May 2008 01:49:33 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m4V1nIoP030810; Fri, 30 May 2008 21:49:26 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-threads@freebsd.org Date: Fri, 30 May 2008 21:45:49 -0400 User-Agent: KMail/1.9.7 References: <483FA1C0.2010506@freebsd.org> <20080530184141.GG48790@elvis.mu.org> In-Reply-To: <20080530184141.GG48790@elvis.mu.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200805302145.49524.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Fri, 30 May 2008 21:49:27 -0400 (EDT) X-Virus-Scanned: ClamAV 0.91.2/7300/Fri May 30 19:42:28 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: David Xu Subject: Re: pthread_cleanup_push as a macro 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: Sat, 31 May 2008 01:49:33 -0000 On Friday 30 May 2008 02:41:41 pm Alfred Perlstein wrote: > * David Xu [080529 23:40] wrote: > > I would like to make pthread_cleanup_push and pthread_cleanup_pop as a > > pair of macros, the current implementation has to malloc() and free() a > > pthread_cleanup memory block everytime, this is slow, the new one > > simply uses stack space, note that other OSes have already done it in > > this way. The patch keeps old functions and should not have binary > > compatible problem. > > > > http://people.freebsd.org/~davidxu/patch/pthread_cleanup_push.patch > > Heh, when I had to use QNX on a project this totally confused > me, but if others are doing it then go for it. > > Does Solaris do it? It's explicitly documented in the standard that push and pop may be implemented as macros and that they have to be paired at the same block level (i.e. it's permitted for push to start a new block and declare a new local variable and for pop to end that block similar to DROP_GIANT/PICKUP_GIANT in the kernel). Internally the thread libraries already do this for internal push/pops to avoid deadlocks. -- John Baldwin From owner-freebsd-threads@FreeBSD.ORG Sat May 31 01:55:32 2008 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 9D519106566B; Sat, 31 May 2008 01:55:32 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 7242C8FC1D; Sat, 31 May 2008 01:55:32 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 384491A4D82; Fri, 30 May 2008 18:55:32 -0700 (PDT) Date: Fri, 30 May 2008 18:55:32 -0700 From: Alfred Perlstein To: John Baldwin Message-ID: <20080531015532.GN48790@elvis.mu.org> References: <483FA1C0.2010506@freebsd.org> <20080530184141.GG48790@elvis.mu.org> <200805302145.49524.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200805302145.49524.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: David Xu , freebsd-threads@freebsd.org Subject: Re: pthread_cleanup_push as a macro 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: Sat, 31 May 2008 01:55:32 -0000 * John Baldwin [080530 18:49] wrote: > On Friday 30 May 2008 02:41:41 pm Alfred Perlstein wrote: > > * David Xu [080529 23:40] wrote: > > > I would like to make pthread_cleanup_push and pthread_cleanup_pop as a > > > pair of macros, the current implementation has to malloc() and free() a > > > pthread_cleanup memory block everytime, this is slow, the new one > > > simply uses stack space, note that other OSes have already done it in > > > this way. The patch keeps old functions and should not have binary > > > compatible problem. > > > > > > http://people.freebsd.org/~davidxu/patch/pthread_cleanup_push.patch > > > > Heh, when I had to use QNX on a project this totally confused > > me, but if others are doing it then go for it. > > > > Does Solaris do it? > > It's explicitly documented in the standard that push and pop may be > implemented as macros and that they have to be paired at the same block level > (i.e. it's permitted for push to start a new block and declare a new local > variable and for pop to end that block similar to DROP_GIANT/PICKUP_GIANT in > the kernel). Internally the thread libraries already do this for internal > push/pops to avoid deadlocks. I figured it was "OK", just was interested in how Solaris did it. -- - Alfred Perlstein From owner-freebsd-threads@FreeBSD.ORG Sat May 31 10:36:54 2008 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 C0FF9106564A; Sat, 31 May 2008 10:36:54 +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 7CE558FC18; Sat, 31 May 2008 10:36:54 +0000 (UTC) (envelope-from deischen@freebsd.org) 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 m4VAaqqC011220; Sat, 31 May 2008 06:36:53 -0400 (EDT) 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.0 (mail.netplex.net [204.213.176.10]); Sat, 31 May 2008 06:36:53 -0400 (EDT) Date: Sat, 31 May 2008 06:36:52 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: David Xu In-Reply-To: <48408D5E.2010609@freebsd.org> Message-ID: References: <483FA1C0.2010506@freebsd.org> <200805301748.29689.jhb@freebsd.org> <48408D5E.2010609@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-threads@freebsd.org Subject: Re: pthread_cleanup_push as a macro 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: Sat, 31 May 2008 10:36:54 -0000 On Sat, 31 May 2008, David Xu wrote: > Daniel Eischen wrote: >> On Fri, 30 May 2008, John Baldwin wrote: >> >>> On Friday 30 May 2008 02:42:08 am David Xu wrote: >>>> I would like to make pthread_cleanup_push and pthread_cleanup_pop as a >>>> pair of macros, the current implementation has to malloc() and free() a >>>> pthread_cleanup memory block everytime, this is slow, the new one >>>> simply uses stack space, note that other OSes have already done it in >>>> this way. The patch keeps old functions and should not have binary >>>> compatible problem. >>>> >>>> http://people.freebsd.org/~davidxu/patch/pthread_cleanup_push.patch >>> >>> Please do! >> >> I agree - Solaris does this too. I am unsure why you really need >> a strong_reference - I would prefer something that doesn't require >> it. >> > > This becauses original _pthread_cleanup_push and _pthread_cleanup_pop are > functions but not weak aliases, it is to keep compatibility. Yes, but _pthread_cleanup_push and _pthread_cleanup_pop are still functions, you are just adding _imp. Are you afraid of _imp being overridden (if it was a weak alias)? I think another tool you could use is __sym_default(__pthread_cleanup_pop_imp, _pthread_cleanup_pop, FBSD_1.1) -- DE