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

Torvald Riegel <triegel at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |triegel at redhat dot com

--- Comment #1 from Torvald Riegel <triegel at redhat dot com> ---
The sem_wait and sem_timedwait behavior is correct because if they don't
actually block (what you seem to call "uncontended"), then there's no blocking
or suspension that can be cancelled.

Quoting the section in the POSIX spec that you refer to:

It is unspecified whether the cancellation request is acted upon or whether the
cancellation request remains pending and the thread resumes normal execution
if:
* The thread is suspended at a cancellation point and the event for which it is
waiting occurs

If there is a token available in the semaphore, then the event for which
sem_wait could wait arguably has occurred already, or can be considered to
occur atomically with entering the cancellation point.  Thus, we don't need to
check for a cancellation request if we can grab a token.


The shm_open behavior seems like a bug though.

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