From: Jens Gustedt <jens.gustedt@inria.fr>
To: musl@lists.openwall.com
Subject: Re: C threads, v. 6.2
Date: Sat, 30 Aug 2014 09:43:36 +0200 [thread overview]
Message-ID: <1409384616.4476.231.camel@eris.loria.fr> (raw)
In-Reply-To: <20140830053036.GJ12888@brightrain.aerifal.cx>
[-- Attachment #1: Type: text/plain, Size: 4668 bytes --]
Am Samstag, den 30.08.2014, 01:30 -0400 schrieb Rich Felker:
> On Fri, Aug 29, 2014 at 09:01:11PM +0200, Jens Gustedt wrote:
> Unless the intent is to permanently have namespace violations, mtx_t
> must be defined at some point such that it does not have
> pthread_mutex_t as its C++ ABI "struct tag". It could have mtx_t
> (because the specific name is reserved), or something like __mtx_t
> (with a name in a general reserved namespace). This requires being a
> different type from pthread_mutex_t.
Are we master of that decision, or do we have to coordinate that with
other C libraries?
> > There is basically one base choice to make:
> >
> > - we decide if pthread_mutex_t and mtx_t are seen as two different
> > types or not for any application that includes both headers
>
> This is not a choice; it's mandated by the fact that our
> pthread_mutex_t has a "struct tag" (in C++) that's a namespace
> violation for use as the tag for mtx_t.
We could probably also find a trick that has us clean on the C side,
and have namespace violation just in a C++ context :)
> However, by the C rules, they're only "different types" when they're
> both visible in the same translation unit. To a translation unit where
> only one is visible, since the typedef name is not actually part of
> the type, just an alias, both are structures without tags, and the one
> that is visible is _the same type_ as whichever one it needs to be to
> make the code correct.
>
> I don't see any problem if an application has both types visible in
> one of it's TUs, since no "aliasing" takes place on the app side. The
> tagless structure "struct { union {...} __u; }" (whichever instance of
> it) is simply zero-initialized on the application TU side. On the
> implementation side, functions like pthread_mutex_trylock access a
> tagless structure "struct { union {...} __u; }", of which they have
> only one defined: the one referenced by the pthread_mutex_t typedef.
As I said, on the side of the current C thread implementation that
needs a thorough revision to be sure that none of the TU sees two
types. I'll look into that.
> > (This should be made independent of the question if we silently use
> > the same hidden type, or similar structured type, under the hood.)
> >
> > For C this choice is not so relevant, since all interfaces are just
> > pointers to struct, so they are interchangeble, and this helps for the
> > implementation.
> >
> > For C++ this is not the same because "type" for them means *typename*,
> > defined in addition that is determined in some subtle and not so
> > obvious way.
> >
> > For backward compatibility, the C++ ABI seems to dictate that there
> > must be at least one such type that is called pthread_mutex_t. So we
> > have to keep the type with that typename for them, it is as simple as
> > that.
> >
> > Now in a C++ context that choice above boils down to the question
> >
> > - is mtx_t a typedef to pthread_mutex_t or is it a proper type?
> >
> > If we want it to be a proper type (for which I would argue, I think)
> > we have to think of ways to make C++ believe that the two types are
> > different, even if we use the same implementation underneath.
>
> Yes, because of the namespace, C++ has to believe the types are
> different. But the (C) implementation of the functions is not subject
> to C++ rules about types; it's not C++ code. Thus I think everything
> is fine.
>
> If you really still think there's a problem, I still have one trick
> I've mentioned before that makes it a 100% non-problem: never using
> the pthread_mutex_t or mtx_t type at all internally, but instead using
> the type of their first member. I believe I could make this work with
> only a few lines of source-level changes, no change to the output
> code, and minimal ugliness. Let me know if you still have doubts
> whether the above analysis I gave is correct, and if so, I'll give my
> trick a try.
So let us talk through this, I suspose the main change that you would
do for that is to change the accessor macros such that they have the
additional indirection. I can see that this would easily work for the
pthread TU.
For the C thread TU, what would be the mechanics for them to call one
of the (aliased) pthread functions?
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 ::
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
next prev parent reply other threads:[~2014-08-30 7:43 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-27 22:11 Jens Gustedt
2014-08-27 23:46 ` Rich Felker
2014-08-28 9:40 ` Jens Gustedt
2014-08-28 11:41 ` Szabolcs Nagy
2014-08-28 16:15 ` Rich Felker
2014-08-28 19:28 ` Jens Gustedt
2014-08-28 20:00 ` Rich Felker
2014-08-28 20:55 ` Szabolcs Nagy
2014-08-28 21:38 ` Jens Gustedt
2014-08-28 21:34 ` Jens Gustedt
2014-08-28 21:56 ` Rich Felker
2014-08-28 23:25 ` Jens Gustedt
2014-08-28 23:38 ` Rich Felker
2014-08-29 7:56 ` Jens Gustedt
2014-08-29 8:02 ` Jens Gustedt
2014-08-29 15:57 ` Rich Felker
2014-08-29 19:01 ` Jens Gustedt
2014-08-30 5:30 ` Rich Felker
2014-08-30 7:43 ` Jens Gustedt [this message]
2014-08-30 8:54 ` Jens Gustedt
2014-08-31 0:30 ` Rich Felker
2014-08-31 1:31 ` Rich Felker
2014-08-31 2:44 ` Rich Felker
2014-08-31 7:09 ` Jens Gustedt
2014-08-29 15:56 ` Rich Felker
2014-08-29 18:40 ` Jens Gustedt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1409384616.4476.231.camel@eris.loria.fr \
--to=jens.gustedt@inria.fr \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).