From 601431090344d2db08f9f19b30a8affb05a7ce0c Mon Sep 17 00:00:00 2001 From: Corinna Vinschen Date: Tue, 22 May 2012 10:28:05 +0000 Subject: * thread.cc (pthread::cancel): Set thread's cancel_event in PTHREAD_CANCEL_ASYNCHRONOUS case, too. Explain why. --- winsup/cygwin/thread.cc | 12 ++++++++++++ 1 file changed, 12 insertions(+) (limited to 'winsup/cygwin/thread.cc') diff --git a/winsup/cygwin/thread.cc b/winsup/cygwin/thread.cc index 1bea526bf..f7ba60a70 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; -- cgit v1.2.3