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/