X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-1.5 required=5.0 	tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS
X-Spam-Check-By: sourceware.org
MIME-Version: 1.0
In-Reply-To: <20090510233629.GC25909@ednor.casa.cgf.cx>
References: <9f8a01cd0905091706s6944a639m8da2f943212cc178 AT mail DOT gmail DOT com> 	 <loom DOT 20090510T004554-316 AT post DOT gmane DOT org> 	 <9f8a01cd0905100245m16838bb9w3c6e494d4a03a4cb AT mail DOT gmail DOT com> 	 <loom DOT 20090510T184100-821 AT post DOT gmane DOT org> 	 <20090510202132 DOT GB25909 AT ednor DOT casa DOT cgf DOT cx> 	 <9f8a01cd0905101533i2902636aub172298be61599a5 AT mail DOT gmail DOT com> 	 <20090510233629 DOT GC25909 AT ednor DOT casa DOT cgf DOT cx>
Date: Mon, 11 May 2009 02:07:51 +0200
Message-ID: <9f8a01cd0905101707x2b91f1edg33ae17ec82ab722e@mail.gmail.com>
Subject: Re: How to detect a cygwin thread?
From: Piotr Wyderski <piotr DOT wyderski AT gmail DOT com>
To: cygwin AT cygwin DOT com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

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 analysi=
s.

> =A0If 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 synchroniza=
tion
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/