On Tue, 2015-08-04 at 11:50 -0700, Nicholas Miell wrote: > On Aug 4, 2015, at 8:06 AM, Roland McGrath <roland@xxxxxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
