[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20200116134147.GM30412@brightrain.aerifal.cx>
Date: Thu, 16 Jan 2020 08:41:47 -0500
From: Rich Felker <dalias@...c.org>
To: "zhaohang (F)" <zhaohang14@...wei.com>
Cc: "musl@...ts.openwall.com" <musl@...ts.openwall.com>,
pengyuanhong <pengyuanhong@...wei.com>
Subject: Re: some doubts about pthread_cancel
On Thu, Jan 16, 2020 at 12:41:25PM +0000, zhaohang (F) wrote:
> 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?
self->cancel remains true, so the request will be acted upon at the
next cancellation point. If your concern is that it won't be acted
upon as soon as the cancellation state is set back to enabled, I
believe that's correct, but there's no requirement for async
cancellation to happen sooner than deferred, only an allowance.
If you think this is a practical problem/QoI issue,
pthread_setcancelstate could be made to check for somethig like
new==PTHREAD_CANCEL_ENABLE && self->cancelasync && self->cancel and to
act on it in that case.
> _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. }
It's needed for the corner case where SIGCANCEL arrives during a
signal handler that's interrupted a cancellation point. The SIGCANCEL
handler has determined that cancellation is not to be acted upon now,
but when the other signal handler (the one it interrupted) returns,
whether to act needs to be evaluated again since it might return to a
point between the evaluation of self->cancel and the syscall
(including restarting the syscall itself) in __syscall_cp_asm.
By re-raising SIGCANCEL but returning from the SIGCANCEL handler with
it blocked, the handler sets up for it to be unblocked atomically with
return of the first signal handler and thereby re-run when the first
signal handler returns.
This cascades for arbitrary levels of nested signal handlers.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
