Fast sigblock (AKA rtld speedup)

John Baldwin jhb at freebsd.org
Mon Jan 14 17:43:52 UTC 2013


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


More information about the freebsd-arch mailing list