On Mon, Jan 24, 2011 at 12:18 AM, Lassi Tuura <[email protected]> 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 _______________________________________________ Libunwind-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/libunwind-devel
