Boost logo

Boost :

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

> 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

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at