From owner-freebsd-toolchain@FreeBSD.ORG Mon Jan 14 17:47:19 2013 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id F3D556A6; Mon, 14 Jan 2013 17:47:18 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (unknown [IPv6:2001:610:1108:5012::107]) by mx1.freebsd.org (Postfix) with ESMTP id BB73090C; Mon, 14 Jan 2013 17:47:18 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 5F321120400; Mon, 14 Jan 2013 18:47:03 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id 4760E2848C; Mon, 14 Jan 2013 18:47:03 +0100 (CET) Date: Mon, 14 Jan 2013 18:47:03 +0100 From: Jilles Tjoelker To: John Baldwin Subject: Re: Fast sigblock (AKA rtld speedup) Message-ID: <20130114174703.GB88220@stack.nl> References: <20130107182235.GA65279@kib.kiev.ua> <20130112053147.GH2561@kib.kiev.ua> <20130112162547.GA54954@stack.nl> <201301141106.07976.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201301141106.07976.jhb@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: toolchain@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 17:47:19 -0000 On Mon, Jan 14, 2013 at 11:06:07AM -0500, John Baldwin wrote: > On Saturday, January 12, 2013 11:25:47 am Jilles Tjoelker wrote: > > With that, I think fast sigblock is too much code and complication > > for a niche case. > It does seem a bit complicated to me as well. > > Most of the extra atomics in multi-threaded applications are > > conditional on __isthreaded (or can be made so); therefore, > > performance loss from linking in libthr should be negligible in most > > cases. > Sadly, this is not true. libstdc++ turns on locking if you merely > link against libthr, not based on testing __isthreaded. (It does this > by testing to see if pthread_once() works during startup, and we have > to intentionally sabotage the pthread_once() in libc to fail for this > to work which annoys me for an entirely different set of reasons.) > At work we go to great lengths to avoid linking in libthr for exactly > this reason (e.g. we have a custom port of boost that builds a > separate set of boost libraries that are explicitly not linked against > libthr), and we also care about exception performance (one of my > co-workers submitted the PR about exception performance). The code which does that check is actually under contrib/gcc. Problem is, they designed __gthread_active_p() to distinguish threaded and unthreaded programming environments -- it must be known in advance and cannot be changed later. The code for the unthreaded environment then takes advantage of this by not even allocating memory for mutexes in some cases. So there is no way around __gthread_active_p() returning true if libthr is linked in. The __isthreaded check will have to be in libthr or in contrib/gcc/gthr-posix.c and it will not do much more than avoiding atomics. This __gthread_active_p() thing is another barrier to bringing in a threaded plugin in an unthreaded application. Ports people spend a fair amount of time adding -pthread flags to things (such as perl) to work around this. -- Jilles Tjoelker