Re: C11 threads ABI questions - enum values

[Rich Felker <dalias at libc dot org>]

On Sun, Aug 17, 2014 at 09:15:25AM +0200, Juan Manuel Torres Palma wrote:
> I was supposed to be working on this but as I said before I'm not
> having as much time as I would like to.
> 
> > For the result codes, Jens Gustedt has proposed matching their
> > definitions with "corresponding" POSIX errno codes. This potentially
> > allows some of the C11 functions to be implemented as aliases for (or
> > tail calls to) POSIX threads functions, but some care is needed since
> > the semantics for the error codes and which conditions they're
> > returned in may not be exactly the same. I'm generally not a fan of
> > this approach, since it pulls in a dependency of target-specific
> > values (the errno values vary widely per target) in a new header that
> > could otherwise be largely arch-generic and requires synchronizing
> > these values without actually including <errno.h> (which is outside
> > the namespace for this header). I would prefer just assigning enum
> > values sequentially from 0 with 0 being success. But I want to see
> > what glibc folks want to do.
> 
> In this topic I think the same way than you do, specially if we want
> to forbid users to do things like matching and comparing types from
> POSIX to C11 threads, so if we use POSIX as a base, we should then
> isolate it to make sure we isolate both libraries.

Even if, implementation-internally, some types can be used
interchangibly, I think it was decided in earlier discussion that such
external usage should be explicitly unsupported, to allow for the
implementations to diverge or be completely independent in the future.

> > 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.
> 
> Well in this case I'm not really sure what to do with mtx_plain and
> mtx_timed, but if they are defined in a different way in the C11
> standard, we need to stick to the standard definition, don't we? I

The C11 standard just says that the enumeration constants need to be
defined, but nothing about their values, or even whether the values
are distinct, so that's really up to us. As Alexander Monakov noted,
however, there does seem to be value in having them be distinct.

> don't really understand why it's useful to match values between
> libraries. I know it easier to implement and makes the coding way
> easier but maybe we can get some not desired uses of them.

Being that mtx_init will presumably be a wrapper that basically does
something like:

__pthread_mutexattr_init
__pthread_mutexattr_settype
__pthread_mutex_init
__pthread_mutexattr_destroy

I don't see any problem having some trivial code to map the C11 type
codes to POSIX type codes before calling __pthread_mutexattr_settype.

To start making some progress, here's a proposed list of values for
enumeration and macro constants in C11 threads.h:

/* Matching what Jens Gustedt proposed for musl, and the order in C
 * standard; also ensuring non-plain types work as bit flags. */
mtx_plain = 0
mtx_recursive = 1
mtx_timed = 2

/* Matching order in the C standard, except that timedout is moved to
 * the end because success should obviously, morally, be zero. :) */
thrd_success = 0
thrd_busy = 1
thrd_error = 2
thrd_nomem = 3
thrd_timedout = 4

/* Matching current pthreads ABI. */
ONCE_FLAG_INIT = 0
TSS_DTOR_ITERATIONS = 4

Did I miss anything? I think the only ones that might be at all
controversial are the thrd_* error codes, and only from a bikeshed
standpoint. Any opinions?

As discussed before, the intent is for all _types_ to match the
corresponding pthread type in size/alignment.

Rich