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 _______________________________________________ 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"
