Re: C11 threads ABI questions - enum values

[Juan Manuel Torres Palma <j dot m dot torrespalma at gmail dot com>]

I agree with the values chosen, and the error codes make sense to me.

The thrd_timedout should be the exit value when a thread can't finish
in a given time right?



2014-08-18 21:49 GMT+02:00 Rich Felker <dalias@libc.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



-- 
Juan Manuel "Lolo" Torres Palma.
Computer Science Student at Universidad de Granada.