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-19 05:52:05

On 12/19/16 01:26, Antony Polukhin wrote:
> 2016-12-18 21:37 GMT+03:00 Andrey Semashev <andrey.semashev_at_[hidden]>:
>> 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.
>
> It's not that simple. After a fork() you are still in the
> async-signal-processing mode. You have to call one of the exec*
> functions to safely print the backtrace.

Ah, right.

> Windows has no fork(). Looks like the only way to do that safely on
> Windows, is to create a process before the signal, make a pipe and
> wait for data on a pipe. As soon as the signal appears - dump data
> into the pipe and die. The child process have to output the content...
> it seems to me that such out-of-the-box functionality won't make all
> the users happy. They would definitely want to tune multiple things
> that I'm failing to predict.

Yes, if the only way to do that is fork+exec then that is not usable for 
me, not as the default implementation of the stacktrace decoding 
algorithm. If such functionality is provided, it should be strictly 
optional and disabled by default (i.e. on Windows don't start the helper 
process unless the user explicitly requests that in runtime). Let the 
decoding algorithm itself be not-signal-safe but in-process.