mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Jens Gustedt <jens.gustedt@inria.fr>
To: musl@lists.openwall.com
Subject: Re: C threads, v. 6.2
Date: Fri, 29 Aug 2014 21:01:11 +0200	[thread overview]
Message-ID: <1409338871.4476.206.camel@eris.loria.fr> (raw)
In-Reply-To: <20140829155744.GH12888@brightrain.aerifal.cx>

[-- Attachment #1: Type: text/plain, Size: 2823 bytes --]

Am Freitag, den 29.08.2014, 11:57 -0400 schrieb Rich Felker:
> On Fri, Aug 29, 2014 at 10:02:43AM +0200, Jens Gustedt wrote:
> > Am Freitag, den 29.08.2014, 09:56 +0200 schrieb Jens Gustedt:
> > > 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.
> > > 
> > > So in conclusion, it is doable, but I don't like it at all.
> > 
> > To give it a positive turn, for the moment I'd prefer to roll this
> > back and have the two types pthread_mutex_t and pthread_cond_t violate
> > the namespace rules of libc for the moment. This is not perfect, but
> > also not a serious drawback.
> > 
> > This would have the advantage of being conservative on the pthread
> > side and not to delay the schedule.
> 
> I don't think this is an acceptable way to proceed. It creates a
> C++ ABI that we're planning to remove by changing the struct tags for
> these types later (fixing the namespace issue will necessarily break
> the C++ ABI).

I don't know what you are planning, could you please explain?

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 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.

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 --]

  reply	other threads:[~2014-08-29 19:01 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 [this message]
2014-08-30  5:30                           ` Rich Felker
2014-08-30  7:43                             ` Jens Gustedt
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=1409338871.4476.206.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).