This is the mail archive of the
mailing list for the Cygwin project.
Re: Signal occasionally causes thread inside win32 api to be suspended?
- From: Christopher Faylor <cgf-use-the-mailinglist-please at cygwin dot com>
- To: cygwin at cygwin dot com
- Date: Mon, 9 Dec 2013 15:47:59 -0500
- Subject: Re: Signal occasionally causes thread inside win32 api to be suspended?
- Authentication-results: sourceware.org; auth=none
- References: <52A4AE10 dot 8080303 at dronecode dot org dot uk>
- Reply-to: cygwin at cygwin dot com
On Sun, Dec 08, 2013 at 05:36:16PM +0000, Jon TURNEY wrote:
>I don't really understand the intricacies of cygwin signal delivery,
>but I see that it can suspend the target thread to determine if it's in
>a safe place to deliver the signal (outside a win32 API call). I think
>that sometimes the thread is not correctly resumed.
>This appears to be the cause of been a long-standing problem with the
>X.org X server on cygwin, which we work around by disabling
>smart-scheduling (no great loss), but I've only just recently
>understood enough about the problem to produce a STC.
>If you run the attached for a while, it stops. According to Process
>Hacker, the main thread is in the suspended state, inside ntdll.dll.
I think I have worked around the problem: calling GetModuleName for the
address associated with ntdll.dll while the thread is suspended can cause
the program (thread?) to hang.
This should be rectified in today's snapshot.
Thanks, as always, for the test case.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple