[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20140907165527.GF23797@brightrain.aerifal.cx>
Date: Sun, 7 Sep 2014 12:55:27 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: [PATCH 1/9] interface additions for the C thread
implementation
On Sun, Sep 07, 2014 at 06:51:12PM +0200, Jens Gustedt wrote:
> <rant>
> Even with those crazy ideas it is easily possible to have the
> corresponding function do such a lacking initialization based on a
> default 0 initialized field, in the same way pthread_once_t
> works. This is a bit of an overhead at each call, but I wouldn't mind
> at all penalizing any implementation that deviates from the
> "all-default-initialization-is-0" rule.
>
> That's already something the standard has for years for pointers and
> floating point. A platform may have different representations for null
> pointers or for 0.0. But it is the problem of the platform provider to
> do everything that 0 initialization does the right thing, and not to
> leave such crazy thing to the user of the type.
> </rant>
I agree totally. In principle you can always have a self-initializing
mutex, since it can use whatever mechanism call_once uses. There is
some cost to this approach, but I don't think it would be
unreasonable. I don't mind encouraging use of call_once though. It's a
shame pthread_once never got more widely publicized/used...
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.
