[PATCH] semctl SUSv2 compliance
authorRusty Russell <rusty@rustcorp.com.au>
Mon, 27 May 2002 04:59:52 +0000 (21:59 -0700)
committerLinus Torvalds <torvalds@home.transmeta.com>
Mon, 27 May 2002 04:59:52 +0000 (21:59 -0700)
commit7cf3b4c630d012ed310b1f87973e2e4204acf7d0
tree30822bbdec63488aeb9af7817ca3d5c9347e3ff3
parentfbce8464001cd33d0a8e22f86b1d96870fe3968b
[PATCH] semctl SUSv2 compliance

Christopher Yeoh <cyeoh@samba.org>: (Made -p1 compliant by rusty) SUSv2 semctl compliance:

  The semctl call with SETVAL currently does not set sempid (at the
  moment sempid is only set during a successful semop call). An
  explanation from Geoff Clare of the Open Group regarding why sempid
  should be set during the semctl call:

  "The spec isn't very clear, but there is a statement on the semget()
  page which I think justifies the assumption made by the test.  It says
  that upon creation, the data structure associated with each semaphore
  in the set is not initialised, and that the semctl() function with
  SETVAL or SETALL can be used to initialise each semaphore.

  Therefore semctl() with SETVAL has to set sempid to *something*, and
  since sempid contains the "process ID of the last operation", setting
  it to anything other than the pid of the calling process would mean
  that sempid contained misleading information.  It could be argued that
  setting it to zero would not be misleading, but zero cannot be the
  process ID of a process, and so is not a valid value for sempid anyway."

  The following patch changes semctl so when called with SETVAL
  sempid is set to the pid of the calling process:
ipc/sem.c