Boost logo

Boost :

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


ned Productions Limited Consulting

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