This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 4/5] nptl: Fix sem_wait and sem_timedwait cancellation
- From: Torvald Riegel <triegel at redhat dot com>
- To: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- Cc: libc-alpha at sourceware dot org
- Date: Fri, 09 Sep 2016 18:32:22 +0200
- Subject: Re: [PATCH 4/5] nptl: Fix sem_wait and sem_timedwait cancellation
- Authentication-results: sourceware.org; auth=none
- References: <1471876053-780-1-git-send-email-adhemerval.zanella@linaro.org> <1471876053-780-4-git-send-email-adhemerval.zanella@linaro.org> <1473098870.20286.22.camel@localhost.localdomain>
On Mon, 2016-09-05 at 20:07 +0200, Torvald Riegel wrote:
> On Mon, 2016-08-22 at 11:27 -0300, Adhemerval Zanella wrote:
> > This patch fixes both sem_wait and sem_timedwait cancellation point for
> > uncontended case. In this scenario only atomics are involved and thus
> > the futex cancellable call is not issue and a pending cancellation signal
> > is not handled.
>
> I have added a comment on the BZ explaining why I think this is NOTABUG.
I've looked at the POSIX rationale again, and it seems I was wrong in my
interpretation of what the POSIX spec requires. I now think that we
need to add the pthread_testcancel call or equivalent. The patch looks
okay, but please also add a comment to the added pthread_testcancel call
explaining why we need it. Something like this may be useful:
We need to check whether we need to act upon a cancellation request here
because POSIX specifies that cancellation points "shall occur" in
sem_wait and sem_timedwait, which also means that they need to check
this regardless whether they block or not (unlike "may occur"
functions). See the POSIX Rationale for this requirement: Section
"Thread Cancellation Overview" in
http://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xsh_chap02.html
See http://austingroupbugs.net/view.php?id=1076 for thoughts on why this
may be a suboptimal design.
Thanks.