This is the mail archive of the 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

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

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