[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Libunwind-devel] Re: [patch 2/2] Allow caller to block signals.

From: Arun Sharma
Subject: Re: [Libunwind-devel] Re: [patch 2/2] Allow caller to block signals.
Date: Fri, 25 Sep 2009 13:04:30 -0700

On Fri, Sep 25, 2009 at 12:00 PM, Mark Rabkin <address@hidden> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]