mailing list of musl libc
 help / color / mirror / code / Atom feed
* [musl] some doubts about pthread_cancel
@ 2020-01-16 12:41 zhaohang (F)
  2020-01-16 13:41 ` Rich Felker
  0 siblings, 1 reply; 2+ messages in thread
From: zhaohang (F) @ 2020-01-16 12:41 UTC (permalink / raw)
  To: musl; +Cc: pengyuanhong

[-- Attachment #1: Type: text/plain, Size: 1268 bytes --]

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.
 }

[-- Attachment #2: Type: text/html, Size: 7710 bytes --]

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [musl] some doubts about pthread_cancel
  2020-01-16 12:41 [musl] some doubts about pthread_cancel zhaohang (F)
@ 2020-01-16 13:41 ` Rich Felker
  0 siblings, 0 replies; 2+ messages in thread
From: Rich Felker @ 2020-01-16 13:41 UTC (permalink / raw)
  To: zhaohang (F); +Cc: musl, pengyuanhong

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2020-01-16 13:44 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-01-16 12:41 [musl] some doubts about pthread_cancel zhaohang (F)
2020-01-16 13:41 ` Rich Felker

Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).