* thread.cc (pthread::cancel): Set thread's cancel_event in

	PTHREAD_CANCEL_ASYNCHRONOUS case, too.  Explain why.

diff --git a/winsup/cygwin/ChangeLog b/winsup/cygwin/ChangeLog
index 1b79569f89f75f999b27fb7bbb7c7631702f67ee..263979b6a2ae6634ba493e591139bb98512214b2 100644 (file)
--- a/winsup/cygwin/ChangeLog
+++ b/winsup/cygwin/ChangeLog
@@ -1,3 +1,8 @@
+2012-05-22  Corinna Vinschen  <corinna@vinschen.de>
+
+       * thread.cc (pthread::cancel): Set thread's cancel_event in
+       PTHREAD_CANCEL_ASYNCHRONOUS case, too.  Explain why.
+
 2012-05-21  Corinna Vinschen  <corinna@vinschen.de>
 
        * strace.cc (strace::activate): Move printing heap size from here...

diff --git a/winsup/cygwin/thread.cc b/winsup/cygwin/thread.cc
index 1bea526bfce6219a6662041ece6126ab5a2227e8..f7ba60a70ff5a28c53636390a1753ea772f386b4 100644 (file)
--- a/winsup/cygwin/thread.cc
+++ b/winsup/cygwin/thread.cc
@@ -566,6 +566,18 @@ pthread::cancel ()
       SetThreadContext (win32_obj_id, &context);
     }
   mutex.unlock ();
+  /* Setting the context to another function does not work if the thread is
+     waiting in WFMO.  For instance, a thread which waits for a semaphore in
+     sem_wait will call cancelable_wait which in turn calls WFMO.  While this
+     WFMO call is cancelable by setting the thread's cancel_event object, the
+     OS apparently refuses to set the thread's context and continues to wait
+     for the WFMO conditions.  This is *not* reflected in the return value of
+     SetThreadContext or ResumeThread, btw.
+     So, what we do here is to set the cancel_event as well.  This allows the
+     WFMO call in cancelable_wait and elsewhere to return and to handle the
+     cancel request by itself. */
+  canceled = true;
+  SetEvent (cancel_event);
   ResumeThread (win32_obj_id);
 
   return 0;