Re: sem_init: pshared=0 difference between Linux and NetBSD

On Tue, Feb 03, 2026 at 07:05:44 -0500, Greg Troxel wrote:

> As the bumper sticker says: What Would Posix Say?
> 
>   https://pubs.opengroup.org/onlinepubs/9799919799/functions/sem_init.html
> 
>     The sem_init() function shall initialize the unnamed semaphore
>     referred to by sem. The value of the initialized semaphore shall be
>     value. Following a successful call to sem_init(), the semaphore can be
>     used in subsequent calls to sem_clockwait(), sem_destroy(),
>     sem_post(), sem_timedwait(), sem_trywait(), and sem_wait(). This
>     semaphore shall remain usable until the semaphore is destroyed. An
>     unnamed semaphore may be implemented using a file descriptor.
> 
>     If the pshared argument has a non-zero value, then the semaphore is
>     shared between processes; in this case, any process that can access
>     the semaphore sem can use sem for performing sem_clockwait(),
>     sem_destroy(), sem_post(), sem_timedwait(), sem_trywait(), and
>     sem_wait() operations.
> 
>     If the pshared argument is zero, then the semaphore is shared between
>     threads of the process; any thread in this process can use sem for
>     performing sem_clockwait(), sem_destroy(), sem_post(),
>     sem_timedwait(), sem_trywait(), and sem_wait() operations.
> 
> That text doesn't strictly say that with pshared=0 that cross-process
> accesses are blocked, but I'd say it is implied strongly enough to be
> the only reasonable interpretation, to the point that I'd expect Austin
> Group to reject a clarification as unnecessary.  I see "is shared
> between the threads of a process" to exclude other sharing.
> 
> I think the NetBSD behavior is a bug.

Well, it would be nice to get a standalone test case to begin with.
The fix at that URL changes the internals of spawn reimplementation
inside libgpg-error, which gpg presumably relies upon.

But if we are into exgetics, I'd note that posix text makes a
distinction.  Shared as a property of a semaphore, and the fact that a
process can access it are not the same.  To summarize the relevant
paragraph:

  1: the [shared] semaphore is shared between processes;
  2: in this case, any process that can access the semaphore sem
  3: can use sem for performing sem_*() operations.

A process can access a semaphore sem (2) that is _not_ shared (1,
negated), but in that case it can _not_ (3, negated) use the semaphore
operations.

The fix in libgpg-error moves around the time the post-syscall hook is
called and I suspect gpg was (indirectly, b/c its hook was called at
the wrong time) doing something like the above, i.e. "using
operations" on a semaphore that it "has access to", but that is not
really shared.

-uwe