Re: lib/53273: sem_init() with pshared=1 does not actually work

[Robert Elz <kre%munnari.OZ.AU@localhost>]

The following reply was made to PR lib/53273; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: lib/53273: sem_init() with pshared=1 does not actually work
Date: Sat, 29 Sep 2018 05:01:00 +0700

     Date:        Fri, 28 Sep 2018 19:50:01 +0000 (UTC)
     From:        David Holland <dholland-bugs%netbsd.org@localhost>
     Message-ID:  <20180928195001.B7B2E7A1F7%mollari.NetBSD.org@localhost>
 
   |  I'm not clear on how that will help - is the idea that you're supposed
   |  to be able to write the bits of the struct through a pipe to another
   |  process and have it work on the other end?
 
 I think the assumption is that the semaphore sits in shared memory.
 Either shared amongst threads (lwps) or between processes (and I
 doubt it matters if it is shm() or mmap() generated).
 
   |  (And while we're at it, the man page for sem_open does not
   |  explain how multiple opens of the same semaphore are supposed to
   |  interact with sem_close, which it should.)
 
 Think of sem_open() and sem_slose() as analogs of open() and close()
 with the difference being that they operate on a different namespace,
 and the operations available on the returned object differ (no read/write/...
 but sem_wait(),  sem_post() etc)..
 
   |  My understanding has always been that if you want to use the same
   |  posix ipc object in multiple processes that you need to name it and
   |  look it up by name in each (with sem_open)...
 
 No, what posix says is ...
 
       any process that can access the semaphore sem can use sem for performing
 
 having the sem in shared mem is what enables other processes to access it.
 
 kre