From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5969 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: C threads, v. 6.2 Date: Thu, 28 Aug 2014 17:56:41 -0400 Message-ID: <20140828215641.GD12888@brightrain.aerifal.cx> References: <1409177505.4476.75.camel@eris.loria.fr> <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> 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 1409263024 6818 80.91.229.3 (28 Aug 2014 21:57:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 28 Aug 2014 21:57:04 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-5976-gllmg-musl=m.gmane.org@lists.openwall.com Thu Aug 28 23:56:55 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 1XN7gc-0004BX-HW for gllmg-musl@plane.gmane.org; Thu, 28 Aug 2014 23:56:54 +0200 Original-Received: (qmail 5903 invoked by uid 550); 28 Aug 2014 21:56:53 -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 5890 invoked from network); 28 Aug 2014 21:56:53 -0000 Content-Disposition: inline In-Reply-To: <1409261653.4476.142.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:5969 Archived-At: On Thu, Aug 28, 2014 at 11:34:13PM +0200, Jens Gustedt wrote: > Am Donnerstag, den 28.08.2014, 16:00 -0400 schrieb Rich Felker: > > On Thu, Aug 28, 2014 at 09:28:09PM +0200, Jens Gustedt wrote: > > > at least it doesn't matter for the standard functions (they are `extern > > > "C"`) but only for user functions with C++ interfaces. > > > > Right, but it matters for all C++ code containing C++ functions that > > use pthread_mutex_t* as an argument. And apparently there's a lot of > > such code. > > > > > Well, ok, so if you could come up with some better idea in the future, > > > let me know. > > > > I'm not even sure it's an issue. I've seen it argued that aliasing > > rules don't even apply here because, when you access something like > > m->_m_lock, that's not an "access" to the structure object/type but to > > the individual member. If that's true, then as long as the structs > > have identical layout, it should be valid to access the members via > > either. > > Yes, there is a special rule for struct types in different TU, that > they are compatible when their internal structure is the same > (including alignment) and if their *tag* name is the same. > > > Also, what is the relationship between two identical struct or union > > types without tags (i.e. the first member of pthread_mutex_t and the > > first member of mtx_t, both of which are unions with no tag)? > > For structs with no tags the situation is more subtle. If you are in > the same TU and declare them in different places they are *not* > compatible, basically they are two different struct. On the other hand > two such struct in different TU are compatible, if they comply to the > above rule of structural equivalence. Do you have a conclusion from this as to whether what we're doing is okay? FWIW the mutex and the code manipulating its internals are always in different TUs. > > > As nsz remarked in his reply, most older compilers don't do anything > > > with it, they just ignore it, though the existence of the nonnull > > > attribute shows that they would be easily capable of doing so. > > > > > > The other inconvenience for `static 1` is C++. They haven't adopted > > > it, so as such this would make the headers incompatible with C++. So > > > also for this one we would need some preprocessor magic. > > > > > > And then, also, it is ugly :( > > > > Yes. Then let's just omit it for now. > > ok > > (you probably mean that also for the nonnull version, I suppose) Yes. > > > > > > > +weak_alias(__pthread_setspecific, pthread_setspecific); > > > > > > > > > > > > It looks like you have a duplicate tss_set for this rather than using > > > > > > the above, so either the above is a grauitous change, or the new > > > > > > tss_set is duplicate code that should be removed. Or did I miss > > > > > > something? > > > > > > > > > > you are right, this should be omitted > > > > > > > > > > (the tss_get code differs in the const qualification of the second argument) > > > > > > > > In this case it's still possible to implement tss_set as a wrapper, > > > > > > I am really allergic against casts, even more if they are somewhat > > > hidden. So I'd do much to avoid that. > > > > There's no cast here. void * converts implicitly to const void *. > > There is a cast inside the pthread_setspecific function which I really > don't like, we discussed that before, I think. I'd rather not use a > function that does const conversion magic under the hood. These are > really badly designed interfaces. Then do you also refrain from using strstr, strchr, etc.? :) I certainly don't see any harm in passing to a pointer which originally has type (void *) through a function that's going to convert it to (const void *) and back to (void *). I could see your objection making sense if the _original_ type were const qualified, but here it's not. In any case I still don't care whether the code gets duplicated or not since it's trivial. So do whichever you like. > > > I know. I'll have a look and try to factor these things out, such that > > > we really can weigh the alternatives. > > > > Can we look at this as a potential post-merge task? I'm skeptical that > > it improves anything; saving maybe 100-200 bytes in the static-linked > > C11-only case is probably not worth spreading code out over multiple > > functions or files and making the flow of pthread_create less obvious. > > I'm willing to look at it if you want to try anyway, but I don't think > > it should be holding up getting C11 threads support added. > > wouldn't be holding up, I promisse. I'd have to factor this into > digestable patches anyhow, so this should not be much more effort. Without this change, it's a tiny patch to pthread_create.c (basically just adding one tiny C11 start function and a few namespace fixes). With it, there's a lot more to do, but my concern isn't whether you have time to do a proposed refactoring of pthread_create; rather, it's the amount of review that will need to go into evaluating whether it's a worthwhile change. Rich