This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug nptl/18243] sem_wait, sem_timedwait are cancellation points shm_open is not


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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]