Re: [Libunwind-devel] Enhanced backtrace cache

[Arun Sharma]

On Mon, Jan 24, 2011 at 12:18 AM, Lassi Tuura <address@hidden> wrote:
> Concerning backtrace() API, the major considerations I had was whether others 
> would be surprised if it retains large hidden persistent state, especially if 
> it does that in every thread it's called to meet the performance objectives.

On a system with ~1000 threads executing similar code, there may be
some advantages to making the cache global, rather than per-thread.
But then we'll need to be careful with atomics.

> Should the 'fast trace' be missing if there is no optimised version? Or 
> should we try to implement it for other archs? Should it fall back on slow 
> trace?

A fast trace stub that returns -UNW_ENOINFO should be good.

>> * off-by-1 problem
>
> Is one of these missing the interrupted vs. called distinction? Which 
> backtrace() did you use, one libunwind or system one?

I ran tests/Ltest-trace v. It seems to be using the libunwind one.

 -Arun