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

Subject: Re: [boost] [Stacktrace] review, please stop discussing non-Stacktrace issues
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2016-12-18 08:56:01

On 17 Dec 2016 at 20:22, Peter Dimov wrote:

> > Ok, but the signal documentation does not allow to use a lot of functions 
> > in signal handlers (syscalls, malloc, printf...). Am I allowed to use COM 
> > functions in signal handlers?
> 
> The signal handlers are fake, they aren't really signal handlers. A crash 
> generates a structured exception on Windows, and the runtime calls the 
> appropriate signal handler when handling that exception. I'm not 100% sure 
> what can be done in a SEH handler, but calling Windows API functions is 
> certainly possible, and this specific COM use - loading an inproc handler 
> and calling it - should be fine too. (In some rare situations, such as 
> crashes in constructors of static objects in DLLs, the loader lock may cause 
> a deadlock, but that's life.) 

Reentering the COM machinery is definitely not safe, it deadlocks 
randomly depending on the threading model used.

I have found that if you preload the COM object and precall all the 
functions you'll call from the async handler, you preexecute all the 
delay loading and lazy binding code. When the async handler is 
called, it will then not reenter the COM machinery, thus avoiding 
deadlocks.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/