Re: [Libunwind-devel] Updated fast trace patch with initial performance results

[Lassi Tuura]

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