On Thu, Dec 22, 2016 at 2:09 AM, Vladimir Batov
On 12/22/2016 08:28 AM, Andrey Semashev wrote:
On 12/21/16 22:43, Antony Polukhin wrote:
* reviewers wish to have a smaller size of the `stacktrace` class, want to avoid template parameter and have a std::vector<frames> like interface (this is async unsafe because vector does dynamic allocations).
Actually, that depends on the allocator. A stack-based allocator or an allocator backed by static storage could be async-safe, making `vector` async-safe as well.
I am not sure about a stack-based allocator as I'd expect the stack to be wiped out but a static-storage allocator sounds like an excellent idea to deal with many/all async-related issues.
The idea is that the stack-based allocator is used in a signal handler. The stacktrace created in that context cannot escape the signal handler and can be used e.g. to save the backtrace to a file. The static storage fits that use case as well, although care must be taken to avoid concurrency issues. Perhaps, a thread-specific static storage would be an even better alternative.
Could that be the default?
I don't think that would make a good default. After all, when you create a stacktrace in the normal code you most likely want it to be independent from the current stack frame or global state.