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

Subject: Re: [boost] [Stacktrace] review, please stop discussing non-Stacktrace issues
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2016-12-17 13:17:02

On 17 Dec 2016 at 19:47, Peter Dimov wrote:

> Antony Polukhin wrote:
> > Actually, it's the other way around: everything is async-signal unsafe
> > https://msdn.microsoft.com/en-us/en-en/library/xdkz3x12.aspx :
> >
> > "Do not use any function that generates a system call (for example, 
> > _getcwd or time)."
> 
> There are no signals on Windows. They just don't exist. The signal function 
> is provided by the C runtime and emulates signals.

There seems to be a lot of muddled discussion here.

Of course Windows has signals, as already referred to by myself 
earlier it's called vectored exception handling which is exactly the 
same as a signal implementation. In an exception handler you cannot 
call any async unsafe routine such as anything in MSVCRT nor anything 
implemented by kernel32.dll in userspace. As on POSIX, almost all 
syscalls implemented entirely in kernel space are safe.

With respect to Stacktrace, that means that if you installed a 
SIGSEGV handler and wanted to print a stacktrace from it before fatal 
exit, you have exactly the same limitations on Windows as on POSIX. 
You can't call printf, you can't call malloc. You can't use ostream.

This is why I hinted at the usage of std::string in Stacktrace's API. 
As far as I can tell, this API design choice precludes the use of 
Stacktrace in any SIGSEGV handlers.

Antony makes the valid point that on Windows there are race problems 
with the DbgHelp library, in fact not only is it not async-unsafe, 
it's also thread-unsafe. Trying to symbolise a stacktrace from 
multiple threads concurrently on Windows will therefore misoperate.

Is this okay with the Boost community or do you feel it is a problem? 
Specifically:

1. Should Stacktrace be async safe so it can be used to print a 
stacktrace from a signal/exception handler?

2. Is its lack of thread safety on Windows a problem?

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/