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.
I'd like to avoid functions that are async-safe on one platform and async unsafe on other. Mixing safety is a perfect way for producing issues in user code.
Well, at least some of the code will be correct then, as opposed to none today.
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.
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.