From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6127 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH 1/9] interface additions for the C thread implementation Date: Sun, 7 Sep 2014 12:55:27 -0400 Message-ID: <20140907165527.GF23797@brightrain.aerifal.cx> References: <20140907002123.GX23797@brightrain.aerifal.cx> <1410081238.4856.137.camel@eris.loria.fr> <1410088603.4856.146.camel@eris.loria.fr> <20140907113220.GB23797@brightrain.aerifal.cx> <1410101101.4856.158.camel@eris.loria.fr> <20140907151610.GD23797@brightrain.aerifal.cx> <1410108672.4856.162.camel@eris.loria.fr> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1410108947 24992 80.91.229.3 (7 Sep 2014 16:55:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 7 Sep 2014 16:55:47 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6140-gllmg-musl=m.gmane.org@lists.openwall.com Sun Sep 07 18:55:40 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1XQfka-00008D-55 for gllmg-musl@plane.gmane.org; Sun, 07 Sep 2014 18:55:40 +0200 Original-Received: (qmail 1625 invoked by uid 550); 7 Sep 2014 16:55:39 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 1617 invoked from network); 7 Sep 2014 16:55:39 -0000 Content-Disposition: inline In-Reply-To: <1410108672.4856.162.camel@eris.loria.fr> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:6127 Archived-At: On Sun, Sep 07, 2014 at 06:51:12PM +0200, Jens Gustedt wrote: > > 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. > 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