musl - some doubts about pthread

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date: Thu, 16 Jan 2020 12:41:25 +0000
From: "zhaohang (F)" <zhaohang14@...wei.com>
To: "musl@...ts.openwall.com" <musl@...ts.openwall.com>
CC: pengyuanhong <pengyuanhong@...wei.com>
Subject: some doubts about pthread_cancel

Hi,

I have two doubts about pthread_cancel in musl v1.1.22.

static void cancel_handler(int sig, siginfo_t *si, void *ctx)
 {
         pthread_t self = __pthread_self();
         ucontext_t *uc = ctx;
         uintptr_t pc = uc->uc_mcontext.MC_PC;
          a_barrier();
         if (!self->cancel || self->canceldisable == PTHREAD_CANCEL_DISABLE) return;

1. If try to cancel a thread which is asynchronous and cancel-disable, the handler of SIGCANCEL will return directly here and it seems that the cancellation request is not remained queued. It makes me confused how this thread will be assured to cancel after it enables cancellation?
          _sigaddset(&uc->uc_sigmask, SIGCANCEL);
          if (self->cancelasync || pc >= (uintptr_t)__cp_begin && pc < (uintptr_t)__cp_end) {
                 uc->uc_mcontext.MC_PC = (uintptr_t)__cp_cancel;
 #ifdef CANCEL_GOT
                 uc->uc_mcontext.MC_GOT = CANCEL_GOT;
 #endif
                 return;
         }
          __syscall(SYS_tkill, self->tid, SIGCANCEL);

2. Why send SIGCANCEL again here? I think self->cancel is enough to judge whether a deferred thread has been cancelled, and furthermore SIGCANCEL is added to uc->uc_sigmask so that SIGCANCEL will not be handled again.
 }

Content of type "text/html" skipped

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.