This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: For review: nptl(7) man page
- From: Torvald Riegel <triegel at redhat dot com>
- To: Nicholas Miell <nmiell at gmail dot com>
- Cc: Roland McGrath <roland at hack dot frob dot com>, Rich Felker <dalias at libc dot org>, "Michael Kerrisk (man-pages)" <mtk dot manpages at gmail dot com>, "linux-man at vger dot kernel dot org" <linux-man at vger dot kernel dot org>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>, "Carlos O'Donell" <carlos at redhat dot com>
- Date: Wed, 05 Aug 2015 11:36:33 +0200
- Subject: Re: For review: nptl(7) man page
- Authentication-results: sourceware.org; auth=none
- References: <550ED3F4 dot 1080403 at gmail dot com> <550F363B dot 801 at gmail dot com> <55B1EFFA dot 9070608 at gmail dot com> <CAODz2cDq4o85NOzqCDg9cH8eCvqt3Tq5QXKMMJtXbik5h5bL+Q at mail dot gmail dot com> <55B54215 dot 6070502 at gmail dot com> <1438616740 dot 20974 dot 81 dot camel at localhost dot localdomain> <20150803200825 dot GJ16376 at brightrain dot aerifal dot cx> <20150804150648 dot 9E9F42C3B01 at topped-with-meat dot com> <3848244D-C3FE-4FD1-B137-AF7AD6252659 at gmail dot com>
On Tue, 2015-08-04 at 11:50 -0700, Nicholas Miell wrote:
> On Aug 4, 2015, at 8:06 AM, Roland McGrath <roland@hack.frob.com> 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 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.