Re: [boost] Stacktrace review: concern, probable solution and review news

Subject: Re: [boost] Stacktrace review: concern, probable solution and review news
From: Vladimir Batov (Vladimir.Batov_at_[hidden])
Date: 2016-12-22 15:06:51

On 12/22/2016 10:21 AM, Andrey Semashev wrote: 

> ... 
> 
> The idea is that the stack-based allocator is used in a signal
> handler. The stacktrace created in that context cannot escape the
> signal handler and can be used e.g. to save the backtrace to a file.

 I hate to sound like a broken record but every time I read "to a file"
I get concerned as it does not seem to fit our deployment case. Airline
scheduling and disruption management. There are people on call 24/7 to
address the situations when our s/w crashes. The operators have no
issues/difficulties with the logs and, in fact, they send us those
automatically without asking. It is really a stretch expecting them to
find, handle, copy files or to run an extra application. Probably doable
but I am not convinced. So, retrieving such a file from their secured
system will be a royal pain. I might have missed that but dumping the
textual stack-trace to the log is still on the cards, right?

> The static storage fits that use case as well, although care must be
> taken to avoid concurrency issues. Perhaps, a thread-specific static
> storage would be an even better alternative.

 Yes, thread_local certainly seems in order... Although I am under
impression that POSIX signals are delivered to only one thread and, when
that happens, the other threads are stopped. If so, then no need for
thread_local... But I am admittedly hazy on handling signals in MT
environment.