This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Backtrace library [3/3]
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Janne Blomqvist <blomqvist dot janne at gmail dot com>
- Cc: Ian Lance Taylor <iant at google dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 14 Sep 2012 11:01:32 +0200
- Subject: Re: Backtrace library [3/3]
- References: <CAO9iq9Hb6_Whi+x1axO_ewzUqinKH9_OZod3EDRP0wEkk1bF9w@mail.gmail.com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Fri, Sep 14, 2012 at 11:50:31AM +0300, Janne Blomqvist wrote:
> A few quick comments,
>
> 1) Although mmap is not guaranteed to be async-signal-safe, in
> practice it should be as you mentioned previously. However I see that
> when using mmap, the implementation uses pthread mutexes. These are
> not guaranteed to be async-signal-safe either, but I guess in practice
Not just not guaranteed, tho locking is just not async-signal-safe.
> as long as you don't try to use the same mutex in "normal" code and
> the signal handler (in this case, the same state struct), it should be
> OK. Is this so?
At least if you get interrupted by async signal while in libbacktrace
(trying to acquire/release some lock or hold it), you'd be definitely out of
luck. File locking could be used as async signal safe locking, but then
there is still the case of what to do when backtrace* is invoked while the
"lock" is held. If the locking is just about initialization of the DWARF
reader, then you might want to prepare everything and just atomically change
some global pointer.
Jakub