[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 5 Jul 2017 08:30:14 +0200
From: Jens Gustedt <jens.gustedt@...ia.fr>
To: musl@...ts.openwall.com
Subject: move to a proper __lock_t type
Hello,
On Tue, 4 Jul 2017 18:28:42 -0400 Rich Felker <dalias@...c.org> wrote:
> On Wed, Jul 05, 2017 at 01:24:23AM +0300, Alexander Monakov wrote:
> > On Tue, 4 Jul 2017, Rich Felker wrote:
> >
> > > Thanks, applying.
> >
> > Can you please document the rationale for using bare ints instead
> > of an explicit struct for internal locks?
>
> I don't think there was/is any good one, it was just the choice that
> was made at the time. At one point there might have been places it
> avoided need for including a header to define the type, or where being
> explicit about the storage needed for the lock mattered (think stdio
> FILE layout, but it uses its own lock anyway), but I think it was
> mostly unjustified. I wouldn't be opposed to changing it.
So what would you think of the following migration path:
(1) Finish the volatile/atomic cleanup by adding a_load, a_load_l and
perhaps corresponding store primitives.
(2) Replace all occurences of "volatile int[2]" by "__lock_t" that
encapsulates just that in a struct.
(3) Replace the __lock/__unlock pair by the new algorithm
(4) Reduce "__lock_t" to a struct that simply has a "volatile int" as
sole member.
In all of that, would we need the "__" in the name of the structure? I
think this name will never be exported.
Jens
--
:: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536 ::
:: :::::::::::::::::::::: gsm France : +33 651400183 ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::
Content of type "application/pgp-signature" skipped
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.
