Re: [PATCH] Don't set sempid in semctl syscall.

[Michael Kerrisk]

On Sat, Feb 27, 2016 at 9:42 AM, PrasannaKumar Muralidharan
<prasannatsmkumar@xxxxxxxxx> 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/