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?
-Alfred
_______________________________________________
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
