Messages in this thread | | | From | Michael Kerrisk <> | Date | Sun, 28 Feb 2016 20:16:49 +0100 | Subject | Re: [PATCH] Don't set sempid in semctl syscall. |
| |
On Sat, Feb 27, 2016 at 9:42 AM, PrasannaKumar Muralidharan <prasannatsmkumar@gmail.com> wrote: > Agreed. Is it better to change the man page and document the behaviour?
Requoting text I just added to the Bugzilla report to explain why the right approach seems to be to document, rather than change this behavior:
So, given that there is implementation variation that probably predates POSIX.1 (I'm assuming that the OpenSolaris behavior has an ancestry that stretches way back), I'd argue that the fault here lies with POSIX, inasmuch as it failed to capture the full variation in existing implementation behavior. (The BSD implementations of System V IPC were post facto.) Generally POSIX.1 does not try to prescribe away existing implementation behavior, but instead creates a loose spec, not that an implementation "may do such and such".
I've added the following text to the semctl(2) man page:
The sempid value POSIX.1 defines sempid as the "process ID of [the] last opera‐ tion" on a semaphore, and explicitly notes that this value is set by a successful semop(2) call, with the implication that no other interface affects the sempid value.
While some implementations conform to the behavior specified in POSIX.1, others do not. (The fault here probably lies with POSIX.1 inasmuch as it likely failed to capture the full range of existing implementation behaviors.) Various other implemen‐ tations also update sempid for the other operations that update the value of a semaphore: the SETVAL and SETALL operations, as well as the semaphore adjustments performed on process termina‐ tion as a consequence of the use of the SEM_UNDO flag (see semop(2)).
Linux also updates sempid for SETVAL operations and semaphore adjustments. However, somewhat inconsistently, it does not update sempid for SETALL operations. While the SETALL behavior might be viewed as a bug, the behavior is longstanding, and is probably unlikely to change.
Cheers,
Michael
-- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Author of "The Linux Programming Interface", http://blog.man7.org/
| |