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

18 Dec 2016

      2016-12-18 21:37 GMT+03:00 Andrey Semashev :
...
On 12/18/16 20:15, Antony Polukhin wrote:
...
2016-12-18 0:29 GMT+03:00 Andrey Semashev :
...
On Sat, Dec 17, 2016 at 9:17 PM, Niall Douglas
 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.

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.

-- 
Best regards,
Antony Polukhin