[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170624222816.GY1627@brightrain.aerifal.cx>
Date: Sat, 24 Jun 2017 18:28:16 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: flag 128
On Sat, Jun 24, 2017 at 12:12:23PM +0200, Jens Gustedt wrote:
> There is also one weird use of flag 128 in sem_init. Semantically it
> encodes "private" so the complement of a shared flag as used for
> mutexes:
>
> sem->__val[2] = pshared ? 0 : 128;
>
> Musl only uses this as a Boolean, so the semantic would be the same if
> we'd just have
>
> sem->__val[2] = !pshared;
>
> Do you have any recollection if the "128" was needed for
> compatibility, or is this just an artefact?
I think it was just an artefact of wanting to be able to pass it
directly to __wait and __wake and have them use it directly, which
they did a long time ago -- but the code was disabled because it
didn't work on kernels without private futex support. Ever since we've
actually used private flag, I'm pretty sure they've always treated it
as a boolean.
Note that it is preferable not to break the representation of pshared
objects (for ABI-compat across static binaries with different
versions) but since the value is just passed to __wake/__wait, I don't
think it matters if it's 1 or 128. It might be best to just leave it
alone for now though -- fewer gratuitous changes to worry about, less
risk of breaking things.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
