On Fri, Sep 25, 2009 at 12:00 PM, Mark Rabkin <[email protected]> wrote: > > If you're now planning to block additional signals in your own client code > ("at the top level"), are you removing the calls inside libunwind to ensure > it doesn't unblock them (as it does SETMASK), or are you just removing them > for performance since they're unnecessary as your initial message implies? >
There were some users of libunwind who didn't like the sigprocmask() system calls generated by libunwind (there were both performance and usability reasons). Paul's patch to test-async-sig.c shows how reentry into libunwind in the same thread can be prevented via a thread local variable without doing a sigprocmask at the top level. > Finally, I just wanted to get a clarification on the effects of linking > libunwind -- it was my impression that linking it may also affect the stack > unwinding done when, for instance, a C++ exception is thrown. Is that not > the case by default? You had mentioned that you use libunwind only for > manually generated stack traces (as is my intention as well), so I wanted to > make sure there's nothing special to be done to prevent libunwind from > taking over some standard symbols that may affect other program behavior. In 0.99, the default is to disable C++ exception handling, so there are no side effects. ./configure --enable-cxx-exceptions gives the old behavior. -Arun _______________________________________________ Libunwind-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/libunwind-devel
