This is the mail archive of the
glibc-bugs@sourceware.org
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: <bug-18243-131@http.sourceware.org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=18243
--- Comment #4 from Torvald Riegel <triegel at redhat dot com> ---
I looked at the POSIX rationale again
(http://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xsh_chap02.html,
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
http://austingroupbugs.net/view.php?id=1076
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.