On 12/22/2016 08:28 AM, Andrey Semashev wrote:
On 12/21/16 22:43, Antony Polukhin wrote:
Hi,
* reviewers wish to have a smaller size of the `stacktrace` class, want to avoid template parameter and have a std::vector<frames> like interface (this is async unsafe because vector does dynamic allocations).
Actually, that depends on the allocator. A stack-based allocator or an allocator backed by static storage could be async-safe, making `vector` async-safe as well.
I am not sure about a stack-based allocator as I'd expect the stack to be wiped out but a static-storage allocator sounds like an excellent idea to deal with many/all async-related issues. Could that be the default? I'd really like the default-deployment case to be as automatic as possible... so that I could use it without wrecking my brain and to make sure junior developers are not repelled by the complexity and actually use it.
...
* Provide async-safe functions that dump addresses separated by whitespace (format also acceptable by addr2line and atos): * `void dump_stacktrace(int fd)` * `void dump_stacktrace(HANDLE fd)` * `void dump_stacktrace(const char* filename)`
Yes, if that's in addition to the non-async-safe function that decodes the stacktrace in-process.
Yes, please. "Decoding the stacktrace in-process" seems very desirable.
...
* Provide an example with dumping callstack to a file and printing it on program restart
I would suggest an example of printing the stacktrace by a separate program. Printing the stacktrace upon restart seems like a contrived case.
Printing the stacktrace upon restart does seem like unusual that might take some getting used to. Still, I personally find quite an attractive alternative to a separate/additional/extra program necessary to retrieve the info.