On 08/05/2015 08:23 PM, Rich Felker wrote:

On Wed, Aug 05, 2015 at 11:14:32AM -0700, Nicholas Miell wrote:

quoted

quoted

On Aug 5, 2015, at 2:36 AM, Torvald Riegel [off-list ref] wrote:

quoted

On Tue, 2015-08-04 at 11:50 -0700, Nicholas Miell wrote:

quoted

On Aug 4, 2015, at 8:06 AM, Roland McGrath [off-list ref] wrote:

I think we are asserting that they are exactly that by dint of the confstr
results for _CS_POSIX_V7_ILP32_OFF32_CFLAGS et al.  So the question is what
POSIX actually does or doesn't say about process-shared synchronization
objects being shared between processes running programs built in different
POSIX compilation environments.

The other relevant question is whether 32/64 sharing of each particular
pshared object has in fact worked reliably under glibc in the past.  Since
we haven't been clear and explicit about the subject before AFAIK, then if
in fact it worked before then people might well have inferred that we made
such an ABI guarantee.  (I hope not, since if so we just broke it.)

The relevant questions aren't what's the least useful behavior
that POSIX lets us get away with or can we leave it broken
because it never worked;'the questions are what do the other
operating systems do and what do the users want.

Those are relevant questions, but they are not the only relevant ones.
Some users would also like to share data structures between processes
using different glibc builds (eg, different versions), and we won't
promise that this works for obvioius reasons.

The reasonable scenario is what we have right now -- 32 and 64-bit
versions of glibc built from the exact same git commit. And I'd
exclude static versions of glibc even if they're the same version.

Why would you exclude static? IMO two static-linked executables using
the same version of glibc should be compatible with each other even if
you don't want to guarantee they'll be compatible with the
same-version shared glibc.

quoted

quoted

The semaphore example shows that there can be a disadvantage to
guaranteeing 32/64b interoperability (specifically, the 64b code is more
efficient).  For mutex, I *currently* don't see a reason why we couldn't
get away with just doing 32b stuff for the pshared case, but there's no
guarantee that I can foresee all future needs either.

Thus, if we would decide to guarantee 32/64b interoperability, we'd need
to have at least strong use cases for that and a decent amount of
confidence that making such a guarantee is unlikely to constrain the
implementation in the future.

Well, POSIX semaphores are supposed to be a replacement for System V
semaphores (and this extends to the rest of the POSIX IPC
primitives); right now they aren't.

Only for some usage cases. As far as I can tell, POSIX semaphores are
not intended to be required to be implemented as a kernel resource.

That last is also true of SysV semaphores, surely?

They don't have permissions enforcement/safety against malicious
processes, 

(I'm a little lost here. POSIX semaphores do have a permissions mask.)

 backout on async process termination, etc.

Actually, System V semaphores don't reliably have this either (see BUGS
in semop(2)).

Cheers,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html