[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1409338871.4476.206.camel@eris.loria.fr>
Date: Fri, 29 Aug 2014 21:01:11 +0200
From: Jens Gustedt <jens.gustedt@...ia.fr>
To: musl@...ts.openwall.com
Subject: Re: C threads, v. 6.2
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 ::
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.
