[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Libunwind-devel] Updated fast trace patch with initial performance
From: |
Lassi Tuura |
Subject: |
Re: [Libunwind-devel] Updated fast trace patch with initial performance results |
Date: |
Wed, 6 Apr 2011 00:13:00 +0200 |
Hi,
> You're right. It doesn't work. We really need a atexit() type API for
> cleaning up on thread exit.
>
> This is generally done by having all pthread_create() calls go through
> your own wrapper. [...]
>
> But libunwind being a library, has no control over how threads are
> created. One possibility is to just provide the hooks that people who
> do have control over their thread creation can call and document it.
Right. Requiring per-thread callback feels a bit unfortunate limitation
to me. Our particular client automatically wraps thread creations so it's
not a problem for us, but it just seems like an unfortunate API to offer.
Would it be worth the trouble and the added complexity to use a lock-free
global (LIFO?) list of trace caches, rather than per-thread one? It would
still need an API call to free accumulated caches, but it wouldn't need to
be tied to thread creation/exit.
I can probably manage to produce lock-free LIFO stack of caches, though I
would definitely appreciate close scrutiny of any such code I produce.
How far do we want to go in attempting to avoid the one calloc()? :-)
Choices seem to be:
a. Use __thread, require per-thread wrapper callbacks from app
b. Use lock-free global cache stack, must still free 'unused' caches.
c. Use pthread_getspecific, deal with calloc from pthread_key_create,
maybe require app to call some init function once at 'safe' time if
it uses unw_backtrace?
I guess I'd go with c, b, then a. We can call once to get the key created
at a safe time (= initialisation for our profiler), then never need to
worry about destructor calls and don't need per-thread callbacks. Failing
that I think I'd prefer b over a.
Regards,
Lassi
- Re: [Libunwind-devel] Updated fast trace patch with initial performance results, (continued)
Re: [Libunwind-devel] Updated fast trace patch with initial performance results, Lassi Tuura, 2011/04/05
Re: [Libunwind-devel] Updated fast trace patch with initial performance results, Lassi Tuura, 2011/04/05
- Re: [Libunwind-devel] Updated fast trace patch with initial performance results, Arun Sharma, 2011/04/05
- Re: [Libunwind-devel] Updated fast trace patch with initial performance results, Lassi Tuura, 2011/04/05
- Re: [Libunwind-devel] Updated fast trace patch with initial performance results, Arun Sharma, 2011/04/05
- Re: [Libunwind-devel] Updated fast trace patch with initial performance results,
Lassi Tuura <=
- Re: [Libunwind-devel] Updated fast trace patch with initial performance results, Arun Sharma, 2011/04/05
- Re: [Libunwind-devel] Updated fast trace patch with initial performance results, Paul Pluzhnikov, 2011/04/05
- Re: [Libunwind-devel] Updated fast trace patch with initial performance results, Arun Sharma, 2011/04/05
- Re: [Libunwind-devel] Updated fast trace patch with initial performance results, Paul Pluzhnikov, 2011/04/05