2016-12-17 19:37 GMT+03:00 Peter Dimov
Antony Polukhin wrote:
Windows implementation of those functions is definitely impossible to make async safe, as the Windows backend uses COM. And that can not be changed :(
I'm not sure that the concept of async safety exists on Windows. Windows doesn't have signals. Or, stated differently, everything is async safe on Windows.
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)."
Yes, I'm planing to provide optimized versions of ostream operators after the review. Windows backend has exactly the same problem.
The problem is that the frame interface has these inherent performance problems. You could optimize op<<, but any user code that doesn't use op<< is still going to have issues. This is an indication that the provided interface is not quite right.
This could be optimized and cached, but in that case library won't be header only and it will get dependencies on boost_thread. Most of the people won't like it. Optimized ostream operators seem to be a lesser evil.
Getting function name and function location in source file are two different COM calls on Windows, so such callback will not work great on Windows.
The cost of initializing and shutting down COM each time dwarfs calling GetNameByOffset. It shouldn't even be a contest.
It also occurs to me that it would be more natural for the backend interface to use size_t get_name(char* buffer, size_t size) instead of string name(), because all the low-level APIs the backends use actually already use the former interface, or something closer to it. Again, not very C++ friendly, but it probably should be at least an option for people who don't want to touch the C/C++ runtime when printing their stack trace, as it could be in an unpredictable state after a crash.
Probably I'm missing some point, but async-signal-safety means almost the same thing. If function is not async-signal-safe you shall not use it in unpredictable states after crash. Anyway, if you do not wish to use C++ runtime after a crash, you definitely would not like to use COM in that place (so std::string in the interface does not make a big difference). -- Best regards, Antony Polukhin