Boost logo

Boost :

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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk