Notes |
(0002364)
dalias (reporter)
2014-08-25 18:44
|
That should read "If any threads in the calling process are currently blocked on the semaphore, the behavior is undefined." Obviously it's permitted to close a semaphore for which other processes have waiters. Presumably it's also permitted to close a semaphore which the current process is still using as long as the reference count will not reach zero, but the reference-counted behavior of named semaphores is not even mentioned in the description of sem_close (only sem_open); this seems to be another error in the description. |
|
(0002399)
geoffclare (manager)
2014-10-02 16:13
|
Interpretation response
------------------------
The standard does not speak to this issue, and as such no conformance
distinction can be made between alternative implementations based on
this. This is being referred to the sponsor.
Rationale:
-------------
There are current implementations which return mmap()ed memory and therefore a sem_close() in this situation on such implementations will result in undefined behavior.
Notes to the Editor (not part of this interpretation):
-------------------------------------------------------
On page 1827 line 58866 after:
The effect of subsequent use of the semaphore indicated by sem by this process is undefined.
add:
If any threads in the calling process are currently blocked on the semaphore, the behavior is undefined. |
|
(0002404)
ajosey (manager)
2014-10-06 07:44
|
Interpretation proposed 6 October 2014 |
|
(0002445)
ajosey (manager)
2014-11-27 10:31
|
Interpretation approved 27 November 2014 |
|