From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6109 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: Sat, 6 Sep 2014 21:19:26 -0400 Message-ID: <20140907011926.GY23797@brightrain.aerifal.cx> References: 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 1410052787 14331 80.91.229.3 (7 Sep 2014 01:19:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 7 Sep 2014 01:19:47 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6122-gllmg-musl=m.gmane.org@lists.openwall.com Sun Sep 07 03:19:41 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 1XQR8m-0003uQ-MX for gllmg-musl@plane.gmane.org; Sun, 07 Sep 2014 03:19:40 +0200 Original-Received: (qmail 19786 invoked by uid 550); 7 Sep 2014 01:19: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 19773 invoked from network); 7 Sep 2014 01:19:39 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:6109 Archived-At: On Mon, Sep 01, 2014 at 12:45:47AM +0200, Jens Gustedt wrote: > This adds all the constant, type and function interfaces. > > It makes pthread_mutex_t, mtx_t, pthread_cond_t and cnd_t different > types. > > This only works because > > - under hood the corresponding pairs of types use exactly the same > definition for the type > > - the types are a struct types without tag name > > - no comparison or assignment is allowed for any of these types. For > the POSIX types this interdiction is written in the standard. For the > C thread types, this is an extension that this implementation > imposes, but which might be integrated in a later version of the C > standard. This would only matter if assignment (comparison of aggregates doesn't even exist in C) were happening between objects of the corresponding C11 and pthread type in the same TU, which is invalid anyway. Nothing in the way these types are implemented precludes assignment between objects of the same type (e.g. mtx_t and mtx_t) or assignment to the opposite (but compatible) type from a different TU (think of pthread_mutex_init writing to a mtx_t in the application via assignment to the dereferenced pthread_mutex_t pointer, which would have been a possible implementation choice for mtx_init). BTW there's nothing in the standard to preclude assignment of mtx_t objects or cnd_t objects that would otherwise be legal, but there's also no reason to think you should be able to use such a copy with the threads.h functions. POSIX explicitly spells out the fact that you can't do this for POSIX sync objects, so if C11 doesn't do the same, this is probably another defect you should file. Obviously it's intended that mtx_t objects could hold handles to a system resource _OR_ actually be the in-memory sync object, so there's no way assignment could be expected to produce an object that well-defined behavior. > - initialization is default initialization of an array of int. For the > POSIX types, initialization expressions are provided. For C thread > types the only initialization foreseen by the standard are the init > functions. I didn't understand what this has to do with the choice of implementation. > - any calls to standard functions use pointers, and because pointer > representations for struct types are the same. The type compatibility rules would also apply to aggregates passed by value between TUs. Rich