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] |
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. e.g.: $ uname -a CYGWIN_NT-5.1 byron 1.7.26(0.271/5/3) 2013-11-29 11:25 i686 Cygwin $ ./signal-in-kernel32 hMod is 0x7c800000 iteration 1 [...] iteration 139325 # stops!
Attachment:
signal-in-kernel32.c
Description: Text document
-- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |