Date: Mon, 14 Jan 2013 12:43:40 -0500 From: John Baldwin <jhb@freebsd.org> To: Alfred Perlstein <bright@mu.org> Cc: Konstantin Belousov <kostikbel@gmail.com>, toolchain@freebsd.org, Jilles Tjoelker <jilles@stack.nl>, freebsd-arch@freebsd.org Subject: Re: Fast sigblock (AKA rtld speedup) Message-ID: <201301141243.40130.jhb@freebsd.org> In-Reply-To: <50F4373B.5080203@mu.org> References: <20130107182235.GA65279@kib.kiev.ua> <201301141106.07976.jhb@freebsd.org> <50F4373B.5080203@mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday, January 14, 2013 11:50:03 am Alfred Perlstein wrote: > On 1/14/13 11:06 AM, 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). > > > I get frustrated when people ask me "but why are you doing that?", but I > have to know... why do we/you need fast exception handling? > > Are you throwing a high rate of exceptions? Or is it just that your > application is that sensitive to exceptions being thrown that a single > slowish one has an impact? More that it is sensitive. Not all exceptions result in an immediate call to exit(). -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201301141243.40130.jhb>