[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: Mark Rabkin
Subject: Re: [Libunwind-devel] Re: [patch 2/2] Allow caller to block signals.
Date: Fri, 25 Sep 2009 16:52:00 -0700
User-agent: Microsoft-Entourage/

Paul, Arun -- thank you both for the clarifications, they were very helpful.

On 9/25/09 1:11 PM, "Paul Pluzhnikov" <address@hidden> wrote:

> On Fri, Sep 25, 2009 at 12:00 PM, Mark Rabkin <address@hidden> wrote:
>> I read this:
>> But I was a little unclear on the main motivation.
>> Was the motivation that the existing signal blocking mechanism didn't
>> prevent re-entry?  If it didn't prevent it, did it cause crashes or aborted
>> stack traces or what was the symptom?
> Existing mechanism did prevent re-entry, but at a cost of lots of
> sigprocmask()s. We have one particular (emulated) environment, where these
> are quite costly.
>> If you're now planning to block additional signals in your own client code
>> ("at the top level"),
> We don't actually need to block them, we just need to make sure that the
> same thread doesn't reenter libunwind from a signal handler....
>> are you removing the calls inside libunwind to ensure
>> it doesn't unblock them (as it does SETMASK),
> The remaining sigprocmask calls are following this pattern:
>   sigprocmask (SIG_SETMASK, &unwi_full_mask, &saved_mask);
>   ret = dl_iterate_phdr (check_callback, as);
>   sigprocmask (SIG_SETMASK, &saved_mask, NULL);
> so (AFAICT) they wouldn't unblock anything that was blocked before.
> But I see now that I should have eliminated these remaining sigprocmasks
> as well. Patch attached.
>> or are you just removing them
>> for performance since they're unnecessary as your initial message implies?
> Yes.
>> 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.
> Not by default. In default configuration on x86_64, I get:
> nm -D src/.libs/ | grep ' T ' | grep -v ' _U'
> 0000000000001380 T backtrace
> So only calls to (glibc) backtrace would be affected.
> Cheers,

reply via email to

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