From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5974 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:56:48 -0400 Message-ID: <20140829155648.GG12888@brightrain.aerifal.cx> References: <20140827234657.GW12888@brightrain.aerifal.cx> <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> 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 1409327829 23820 80.91.229.3 (29 Aug 2014 15:57:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 29 Aug 2014 15:57:09 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-5981-gllmg-musl=m.gmane.org@lists.openwall.com Fri Aug 29 17:57:02 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 1XNOXu-0000gp-EC for gllmg-musl@plane.gmane.org; Fri, 29 Aug 2014 17:57:02 +0200 Original-Received: (qmail 30490 invoked by uid 550); 29 Aug 2014 15:57:01 -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 30482 invoked from network); 29 Aug 2014 15:57:00 -0000 Content-Disposition: inline In-Reply-To: <1409298999.4476.163.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:5974 Archived-At: On Fri, Aug 29, 2014 at 09:56:39AM +0200, Jens Gustedt wrote: > Am Donnerstag, den 28.08.2014, 19:38 -0400 schrieb Rich Felker: > > Perhaps I should clarify: what I mean by "what we're doing" is > > defining pthread_mutex_t and mtx_t as separate structs with identical > > contents (a single union with no tag). Your latest version with > > __pthread_mutex_t is not a possibility because it changes the C++ ABI. > > > > In principle we could do something like with the definition of > > pthread_t where it changes depending on whether the header is being > > used in a C or C++ program, but that's quite ugly and not something > > I'd much like to do... > > > > Is your conclusion still that it's okay? I think so but I just want to > > confirm. > > Ok, now I see. > > (for the discussion let's just take mutexes as example, similar would > apply for cv) > > Yes, done carefully this would be an option. By carefully meaning that > we have to ensure that all TU see only either type, not both. > > For pthread this would be easy, basically nothing changes, good. > > For C threads that base themselves on pthread this would be a pain. We > have to call pthread functions with mutex parameters. We couldn't just > simply include the pthread.h header, since this would drag in the > pthread type definitinions. > > > We could get away with it, by some hackery > > ** Option 1: > > C threads do something like the following in all C thread TU, or have > an intermediate header "threads_impl.h" that does this > > typedef mtx_t pthread_mutex_t > #define __DEFINED_pthread_mutex_t > > #include "pthread_impl.h" > > ** Option 2: > > In "pthread_impl.h" have: > > typedef pthread_mutex_t __pthread_mutex_t; > > In "threads_impl.h" have: > > typedef mtx_t __pthread_mutex_t; > > and then let all __pthread_xxxxx functions that we provide to be used > by the C thread implementation use __pthread_mutex_t. Or maybe, Option 3: Just don't include pthread_impl.h or pthread.h at all in the C11 wrapper files for these types. These are only a few files and they don't need access to any pthread types because they're just wrappers. > 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. How so? The TUs that see both types cannot touch the contents of them at all, since they're opaque types. Also I'm still not convinced that any aliasing of the struct objects happens (there is no access of whole structs, assignment of structs, etc. in the relevant code), only of the int and void* members, which have the correct effective types. Obviously there's a dependency on the layout of the structs matching (no differences in padding, etc.) but we depend on layout being predictable anyway since this is part of the target ABI and cannot change. Rich