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

Subject: Re: [boost] [Stacktrace] review, please stop discussing non-Stacktrace issues
From: Peter Dimov (lists_at_[hidden])
Date: 2016-12-17 11:37:24

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.