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/