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

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
> 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