about summary refs log tree commit diff
path: root/nptl/pthread_join_common.c
diff options
context:
space:
mode:
authorAdhemerval Zanella <adhemerval.zanella@linaro.org>2020-03-31 15:43:25 -0300
committerAdhemerval Zanella <adhemerval.zanella@linaro.org>2021-06-09 15:16:45 -0300
commit2b5174253155bdace1262ea2ab53d11347ecdefd (patch)
tree9992336533dec0f8cd9579e217b7bc7a18d0733e /nptl/pthread_join_common.c
parent26cfbb7162ad364d53d69f6d482f2d87b5950524 (diff)
downloadglibc-2b5174253155bdace1262ea2ab53d11347ecdefd.tar.gz
glibc-2b5174253155bdace1262ea2ab53d11347ecdefd.tar.xz
glibc-2b5174253155bdace1262ea2ab53d11347ecdefd.zip
nptl: Move cancel state out of cancelhandling
Now that thread cancellation state is not accessed concurrently anymore,
it is possible to move it out the 'cancelhandling'.

The code is also simplified: CANCELLATION_P is replaced with a
internal pthread_testcancel call and the CANCELSTATE_BIT{MASK} is
removed.

With this behavior pthread_setcancelstate does not require to act on
cancellation if cancel type is asynchronous (is already handled either
by pthread_setcanceltype or by the signal handler).

Checked on x86_64-linux-gnu and aarch64-linux-gnu.
Diffstat (limited to 'nptl/pthread_join_common.c')
-rw-r--r--nptl/pthread_join_common.c5
1 files changed, 4 insertions, 1 deletions
diff --git a/nptl/pthread_join_common.c b/nptl/pthread_join_common.c
index f842c91a08..7303069316 100644
--- a/nptl/pthread_join_common.c
+++ b/nptl/pthread_join_common.c
@@ -59,7 +59,10 @@ __pthread_clockjoin_ex (pthread_t threadid, void **thread_return,
 	   && (pd->cancelhandling
 	       & (CANCELED_BITMASK | EXITING_BITMASK
 		  | TERMINATED_BITMASK)) == 0))
-      && !CANCEL_ENABLED_AND_CANCELED (self->cancelhandling))
+      && !(self->cancelstate == PTHREAD_CANCEL_ENABLE
+	   && (pd->cancelhandling & (CANCELED_BITMASK | EXITING_BITMASK
+				     | TERMINATED_BITMASK))
+	       == CANCELED_BITMASK))
     /* This is a deadlock situation.  The threads are waiting for each
        other to finish.  Note that this is a "may" error.  To be 100%
        sure we catch this error we would have to lock the data