This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

C11 threads ABI questions - enum values


Hi everyone,

Is there any progress on the C11 threads implementation for glibc? I
would at least like to solidify one ABI question, since we have
someone working on C11 threads for musl and I want to use matching
values for the constants in threads.h. This header defines several
enumeration constants for mutex types and result/error codes:

mtx_plain
mtx_recursive
mtx_timed
thrd_timedout
thrd_success
thrd_busy
thrd_error
thrd_nomem

Of the above, mtx_recursive is a flag which can be or'd with either
mtx_plain or mtx_timed. The rest are independent values.

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.

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.

Rich


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]