JehanneOS/newlib
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

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

Browse Source 
PTHREAD_CANCEL_ASYNCHRONOUS case, too.  Explain why.
This commit is contained in:
Corinna Vinschen 2012-05-22 10:28:05 +00:00
parent 08d7e0c909
commit 6014310903
2 changed files with 17 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
winsup/cygwin/ChangeLog
View File

@ -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> 2012-05-21 Corinna Vinschen <corinna@vinschen.de>
* strace.cc (strace::activate): Move printing heap size from here... * strace.cc (strace::activate): Move printing heap size from here...

12
winsup/cygwin/thread.cc
View File

@ -566,6 +566,18 @@ pthread::cancel ()
SetThreadContext (win32_obj_id, &context); SetThreadContext (win32_obj_id, &context);
} }
mutex.unlock (); 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); ResumeThread (win32_obj_id);
return 0; return 0;