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

[Greg Troxel <gdt%lexort.com@localhost>]

Tom Lane <tgl%sss.pgh.pa.us@localhost> writes:

> Greg Troxel <gdt%lexort.com@localhost> writes:
>> Thomas Klausner <wiz%netbsd.org@localhost> writes:
>>     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.
>
> Au contraire, I'd read that as "the behavior if you try is
> unspecified".  Perhaps an implementation would be bright enough to
> issue an error, or perhaps it'd just malfunction.  Notice that the
> spec does not identify any particular errno that should be used
> by sem_post and friends to report "you tried to access an unshared
> sem from another process".
>
> To my eyes, pshared == 0 licenses the implementation to *assume*
> that no cross-process access will happen.  It doesn't say that the
> implementation is supposed to *enforce* that.  If an application is
> passing zero and then doing cross-process access anyway, that's an
> application bug that might or might not result in observable
> misbehavior.

Having read your comments and those of others, I have come to agree that
cross-process accesses in the case pshared==0 is UB.