X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=-3.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org To: cygwin AT cygwin DOT com From: Mark Geisert Subject: Re: How to detect a cygwin thread? Date: Sun, 10 May 2009 00:49:56 +0000 (UTC) Lines: 20 Message-ID: References: <9f8a01cd0905091706s6944a639m8da2f943212cc178 AT mail DOT gmail DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit User-Agent: Loom/3.14 (http://gmane.org/) X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Piotr Wyderski writes: > My program has a built-in panic handler, which enumerates > all process threads using the CreateToolhelp32Snapshot > WinAPI function and then suspends them (except itself) > in order to freeze the entire environment in a state as close > as possible to the original error conditions. Unfortunately it > also stops the internal Cygwin thread (which seems to spend > most of its time in cygwin1.dll!toascii+0x15d0) and the entire > process hangs. Is there a way to identify those Cygwin > threads in order not to suspend them? Why assume Cygwin could be the only source of extra threads? Wouldn't it make more sense to have your program remember its own threads and only suspend those? Presumably you know when and where your program's threads are created and destroyed, right? ..mark -- 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/