Subject: Re: [boost] [Stacktrace] review, please stop discussing non-Stacktrace issues
From: Antony Polukhin (antoshkka_at_[hidden])
Date: 2016-12-17 12:29:35
2016-12-17 19:37 GMT+03:00 Peter Dimov <lists_at_[hidden]>:
> 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
Actually, it's the other way around: everything is async-signal unsafe
"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
>> Getting function name and function location in source file are two
>> different COM calls on Windows, so such callback will not work great on
> 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
-- Best regards, Antony Polukhin
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk