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
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 acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk