Christopher Faylor wrote: > Yes, that's the signal thread but I don't know why stopping it would > cause any special problems since, if the entire program is stopped, it > isn't going to be processing signals.
I don't know the reason, just report the program's behaviour. But to provide you more context: this code is a critical error handler. All it has to do is: 1. immediately stop the world in a nice way, as this thread is all about. When "sig" is suspended, no more points follow. 2. dump detailed stack traces + module list + the emergency stop reason description to the set of log files; 3. call std::abort in order to generate a core file for post-mortem analysis. > If that is the case, then you are going to see > problems any time a thread is doing blocking I/O. Why is that? MSDN for SuspendThread() indicates no such issue. There is an obvious warning about possible deadlock when the suspended thread has a synchronization object needed by the suspender, but it is not the case here. BTW, is there a plan to support backtrace() and backtrace_symbols() (or something compatible)? The need for parsing DWARF sections by the user himself is a difficult and painstaking challenge. Best regards Piotr Wyderski -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
