Hi Arun, > I'm a bit behind on libunwind related emails/patches, but hope to look > at your patch in more detail in the next week or so.
Thanks. There's no great urgency, but obviously if we can avoid a patch, it's better for us. > I generally like the idea of having a fast back trace with a fall back > to a correct, slower, but more general case. A couple of initial > comments: > > * Why not use a call back based API instead of a backtrace() style API? > For eg: I don't have a strong opinion. All we need is the stack trace, and I suspect there are other similar clients, so callback isn't necessary. We mainly care about making the walk loop as fast as possible since we call into it million times a second. (Or would, if it was fast enough :-)) > * I couldn't tell what is the locking protocol on the frame cache. In > the multi-threaded case, do you expect to have a global frame cache or > a per-thread frame cache? As designed, there's no locking and the caller must ensure the frame cache is not used by any other thread at the same time. The reason for us is that we want to ensure maximum performance, and our current main users don't create so many threads this would be a problem. Also our profiler traps thread creation so it's trivial to set up thread specific caches. I'd be interested how others might desire from a fast walk; the above are just our biases. I imagine the cache could have other uses, it might significantly accelerate ptrace-based walks for example. If we know what people want we have a better chance judging which aspects can be satisfied by a single API. Regards, Lassi _______________________________________________ Libunwind-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/libunwind-devel
