This is the mail archive of the
mailing list for the Cygwin project.
Re: How to detect a cygwin thread?
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.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html