Re: [boost] [Stacktrace] review, please stop discussing non-Stacktrace issues

Subject: Re: [boost] [Stacktrace] review, please stop discussing non-Stacktrace issues
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2016-12-18 13:37:06

On 12/18/16 20:15, Antony Polukhin wrote:
> 2016-12-18 0:29 GMT+03:00 Andrey Semashev <andrey.semashev_at_[hidden]>:
>> On Sat, Dec 17, 2016 at 9:17 PM, Niall Douglas
>> <s_sourceforge_at_[hidden]> wrote:
>>>
>>> Specifically:
>>>
>>> 1. Should Stacktrace be async safe so it can be used to print a
>>> stacktrace from a signal/exception handler?
>>
>> That depends on whether any backend supports decoding the stacktrace
>> in signal handlers. Note that if we also want to load debug symbols
>> from a separate file while doing this, the task seems to become
>> impossible.
>
> Spawning a new subprocess in signal handler (or at the beginning of
> the program) would be OK for you? If I'll came up with an
> async_safe_print(stacktrace()); function that may fix the broken
> example in docs, provide much more motivation for having non
> allocating stacktrace class.

If that is only possible by forking a process then I'm not sure that 
accomplishes much. I mean, if there is a non-signal-safe formatting 
function for stacktraces, there's no problem to call `fork()` yourself 
in the signal handler, use that formatting function in the child 
process, and pipe its result back to the main process. I guess, a helper 
function that does this would be useful, just make sure to explicitly 
document that it forks. Also, the non-forking formatting implementation 
is still needed for all cases other than signal handlers.