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

	PTHREAD_CANCEL_ASYNCHRONOUS case, too.  Explain why.

2 files changed, 17 insertions, 0 deletions

diff --git a/winsup/cygwin/ChangeLog b/winsup/cygwin/ChangeLog
index 1b79569..263979b 100644
--- 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 1bea526..f7ba60a 100644
--- 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;