[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1409268337.4476.151.camel@eris.loria.fr>
Date: Fri, 29 Aug 2014 01:25:37 +0200
From: Jens Gustedt <jens.gustedt@...ia.fr>
To: musl@...ts.openwall.com
Subject: Re: C threads, v. 6.2
Am Donnerstag, den 28.08.2014, 17:56 -0400 schrieb Rich Felker:
> 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.
Yes, what we were doing before and after is ok for C, anyhow. All code
sees exactly the same definitions in the platform specific (generated)
alltypes.h header. All renaming is done through typedef, so there is
no problem at all, this is always the same type, visible through
different names.
And it even would be ok if one TU would only see it as
__pthread_mutex_t and the other TU as pthread_mutex_t, say. As long as
these are typedef to structures with no tags and exactly the same
layout.
The problem only occurs for C++, since they seem to have a concept of
"original name" of a type or so.
> > > > 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.
ok, I'll keep that in mind
Jens
--
:: INRIA Nancy Grand Est ::: AlGorille ::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536 ::
:: :::::::::::::::::::::: gsm France : +33 651400183 ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::
Download attachment "signature.asc" of type "application/pgp-signature" (199 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
