* DevNotes: Add entry cgf-000006.

* thread.cc (pthread::pop_cleanup_handler): Set cancel state to disabled to
avoid recursively waiting for cancel.
This commit is contained in:
Christopher Faylor 2012-05-12 20:26:43 +00:00
parent 348b56b5a3
commit 1f99484812
4 changed files with 25 additions and 0 deletions

View File

@ -1,3 +1,9 @@
2012-05-12 Christopher Faylor <me.cygwin2012@cgf.cx>
* DevNotes: Add entry cgf-000006.
* thread.cc (pthread::pop_cleanup_handler): Set cancel state to
disabled to avoid recursively waiting for cancel.
2012-05-12 Christopher Faylor <me.cygwin2012@cgf.cx>
* DevNotes: Add entry cgf-000005.

View File

@ -1,3 +1,16 @@
2012-05-12 cgf-000006
<1.7.16>
- Fix hang when calling pthread_testcancel in a canceled thread.
Fixes some of: http://cygwin.com/ml/cygwin/2012-05/msg00186.html
</1.7.16>
This should fix the first part of the reported problem in the above
message. The cancel seemed to actually be working but, the fprintf
eventually ended up calling pthread_testcancel. Since we'd gotten here
via a cancel, it tried to recursively call the cancel handler causing a
recursive loop.
2012-05-12 cgf-000005
<1.7.16>

View File

@ -9,3 +9,6 @@ Bug fixes:
- Fix pipe creation problem which manifested as a problem creating a
fifo. Fixes: http://cygwin.com/ml/cygwin/2012-05/msg00253.html
- Fix hang when calling pthread_testcancel in a canceled thread.
Fixes some of: http://cygwin.com/ml/cygwin/2012-05/msg00186.html

View File

@ -1057,6 +1057,9 @@ pthread::pop_cleanup_handler (int const execute)
mutex.lock ();
/* We will no honor cancels since the thread is exiting. */
cancelstate = PTHREAD_CANCEL_DISABLE;
if (cleanup_stack != NULL)
{
__pthread_cleanup_handler *handler = cleanup_stack;