Signal handling and SuspendThread
Sat Dec 17 03:42:00 GMT 2005
On Fri, 2005-12-16 at 21:35 -0500, Christopher Faylor wrote:
> There seems to be a lot of code out there which relies on GetThreadContext
> returning something sane after a SuspendThread, however.
> Does the below patch cause any difference in behavior?
I applied it to the "suspend.cpp" program and ran it on the fastest
machine I've got, and it looks like calling GetThreadContext()
is sufficient to make sure that the thread is suspended.
FWIW, the patch below is what's under testing over here right now.
I'll provide a copy of a cygwin1.dll with your patch to QA and
ask them to use both for torture tests and let you know
the result early next week.
Have a joyous, bug-free Yuletide, everyone!
2005-12-16 Max Kaehn <email@example.com>
* exceptions.cc (setup_handler): since SuspendThread() does not
guarantee that the specified thread has halted before SuspendThread()
returns, we hold on to the tls lock until just before ResumeThread()
RCS file: /cvs/src/src/winsup/cygwin/exceptions.cc,v
retrieving revision 1.268
diff -u -p -r1.268 exceptions.cc
--- exceptions.cc 7 Dec 2005 11:16:47 -0000 1.268
+++ exceptions.cc 16 Dec 2005 23:33:53 -0000
@@ -758,7 +758,6 @@ setup_handler (int sig, void *handler, s
- tls->unlock ();
HANDLE hth = (HANDLE) *tls;
@@ -783,12 +782,13 @@ setup_handler (int sig, void *handler, s
/* Just set pending if thread is already suspended */
+ tls->unlock ();
- if (tls->incyg || tls->spinning || tls->locked ())
- sigproc_printf ("incyg %d, spinning %d, locked %d\n",
- tls->incyg, tls->spinning, tls->locked ());
+ if (tls->incyg || tls->spinning)
+ sigproc_printf ("incyg %d, spinning %d\n",
+ tls->incyg, tls->spinning);
cx.ContextFlags = CONTEXT_CONTROL | CONTEXT_INTEGER;
@@ -798,6 +798,7 @@ setup_handler (int sig, void *handler, s
interrupted = tls->interrupt_now (&cx, sig, handler, siga);
+ tls->unlock ();
res = ResumeThread (hth);
More information about the Cygwin-developers