From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5975 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: C threads, v. 6.2 Date: Fri, 29 Aug 2014 11:57:44 -0400 Message-ID: <20140829155744.GH12888@brightrain.aerifal.cx> References: <1409218850.4476.96.camel@eris.loria.fr> <20140828161552.GY12888@brightrain.aerifal.cx> <1409254089.4476.137.camel@eris.loria.fr> <20140828200029.GA12888@brightrain.aerifal.cx> <1409261653.4476.142.camel@eris.loria.fr> <20140828215641.GD12888@brightrain.aerifal.cx> <1409268337.4476.151.camel@eris.loria.fr> <20140828233809.GE12888@brightrain.aerifal.cx> <1409298999.4476.163.camel@eris.loria.fr> <1409299363.4476.164.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 1409327888 24473 80.91.229.3 (29 Aug 2014 15:58:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 29 Aug 2014 15:58:08 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-5982-gllmg-musl=m.gmane.org@lists.openwall.com Fri Aug 29 17:57:57 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 1XNOYn-0001WB-FX for gllmg-musl@plane.gmane.org; Fri, 29 Aug 2014 17:57:57 +0200 Original-Received: (qmail 31998 invoked by uid 550); 29 Aug 2014 15:57:56 -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 31987 invoked from network); 29 Aug 2014 15:57:56 -0000 Content-Disposition: inline In-Reply-To: <1409299363.4476.164.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:5975 Archived-At: On Fri, Aug 29, 2014 at 10:02:43AM +0200, Jens Gustedt wrote: > Am Freitag, den 29.08.2014, 09:56 +0200 schrieb Jens Gustedt: > > All of this would explode in our face the day a user wants to use > > pthread_mutex_t and mtx_t in the same application. A use case could be > > that he uses one library that protects CS with pthread_mutex_t and > > another that uses mtx_t. Now suddenly we have code that sees two > > different types, with possibly subtle bugs due to aliasing. > > > > So in conclusion, it is doable, but I don't like it at all. > > To give it a positive turn, for the moment I'd prefer to roll this > back and have the two types pthread_mutex_t and pthread_cond_t violate > the namespace rules of libc for the moment. This is not perfect, but > also not a serious drawback. > > This would have the advantage of being conservative on the pthread > side and not to delay the schedule. I don't think this is an acceptable way to proceed. It creates a C++ ABI that we're planning to remove by changing the struct tags for these types later (fixing the namespace issue will necessarily break the C++ ABI). Rich