This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: C11 threads ABI questions - enum values
- From: Rich Felker <dalias at libc dot org>
- To: libc-alpha at sourceware dot org
- Date: Mon, 18 Aug 2014 15:27:14 -0400
- Subject: Re: C11 threads ABI questions - enum values
- Authentication-results: sourceware.org; auth=none
- References: <20140727203825 dot GA13146 at brightrain dot aerifal dot cx> <alpine dot LNX dot 2 dot 00 dot 1408181622440 dot 743 at monopod dot intra dot ispras dot ru>
On Mon, Aug 18, 2014 at 04:25:57PM +0400, Alexander Monakov wrote:
> On Sun, 27 Jul 2014, Rich Felker wrote:
> > For the mtx types, mtx_plain and mtx_timed really could both have the
> > same value; I can't see there being any reasonable implementation
> > where it would matter at initialization time whether you want to
> > perform timed operations on the mutex or not. And the standard does
> > not seem to preclude this. In that case, the values of mtx_plain and
> > mtx_timed could match the value of PTHREAD_MUTEX_NORMAL and the values
> > or'd with mtx_recursive could match PTHREAD_MUTEX_RECURSIVE. Of course
> > doing this is not necessary and I'm open to other choices of values.
>
> In case the ultimate decision is _not_ to match new enum values with existing
> pthread constants, then in my opinion it's preferable to keep new enum values
> distinct for the sake of future debug or emulation layers that might prefer to
> know in advance the kind of mutex the application meant to use.
Yes, I think there's some value in being able to track what the
calling application _asked_ for, e.g. in the debugger, even if the
request is meaningless from an implementation standpoint.
After thinking about it more, I'm probably mildly in favor of using
enum constants unrelated to the values of the pthread ones (at least
not in any official relationship).
Rich