This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: How to detect a cygwin thread?


On Mon, May 11, 2009 at 02:07:51AM +0200, Piotr Wyderski wrote:
>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.

I wasn't asking for more context.  This isn't a bug in Cygwin.

I'm telling you that I can't think of a good reason for the suspension
of the signal thread to cause a hang other than the fact that Windows
probably doesn't like calling SuspendThread on a thread which is
blocking in ReadFile or something similar.

Your takeaway from this is:

1) I don't care about this.  Not suspending the "sig" thread fixes my
problem.

or

2) I'd better check to see if that is the case since my techniques to
"stop the world" will fail if any thread is calling ReadFile.

>> ?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.

There is nothing in the SuspendThread documentation to indicate that it
*won't* block either.

You might notice the hoops that are jumped through in the Cygwin signal
code to try to call SuspendThread only when it is known to be safe.  We
try hard not to call SuspendThread when the program is in the middle of
a Windows call.  We do that because we're trying to avoid random hangs
and SEGVs which we've noticed through the years when we have attempted
to use SuspendThread.

>BTW, is there a plan to support backtrace() and backtrace_symbols() (or
>something compatible)?

Nope.

cgf

--
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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]