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

On 12/19/16 01:26, Antony Polukhin wrote:

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.

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.