[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140829155744.GH12888@brightrain.aerifal.cx>
Date: Fri, 29 Aug 2014 11:57:44 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: C threads, v. 6.2
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).
Rich
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.
