This is the mail archive of the
mailing list for the glibc project.
[Bug nptl/18243] sem_wait, sem_timedwait are cancellation points shm_open is not
- From: "triegel at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Fri, 09 Sep 2016 16:23:17 +0000
- Subject: [Bug nptl/18243] sem_wait, sem_timedwait are cancellation points shm_open is not
- Auto-submitted: auto-generated
- References: <email@example.com/bugzilla/>
--- Comment #4 from Torvald Riegel <triegel at redhat dot com> ---
I looked at the POSIX rationale again
Section "Thread Cancellation Overview"), and it seems they indeed want
cancellation requests to be acted upon regardless of whether there is blocking
or not. But this *only* applies to functions in which a cancellation point
"shall" occur; "may" functions don't need to check for cancel when they are not
actually blocking, even though they can cancel when blocked -- so "shall" vs.
"may" really also changes not just whether cancellation enabled but also how
it's required to work. This seems like a pretty inconsistent design to me.
For a detailed critique / complaint, see
Nonetheless, sem_wait is a part of the "shall" list, unfortunately, so I agree
that we will have to add the cancellation check. It's unfortunate because it
adds to the fast-path (of any sem_wait implementation), but I guess the Austin
Group is not going to want to change this.
You are receiving this mail because:
You are on the CC list for the bug.