Re: [boost] Stacktrace review: concern, probable solution and review news

Subject: Re: [boost] Stacktrace review: concern, probable solution and review news
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2016-12-21 18:21:16

On Thu, Dec 22, 2016 at 2:09 AM, Vladimir Batov
<Vladimir.Batov_at_[hidden]> wrote:
> 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.