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: Juan Manuel Torres Palma <j dot m dot torrespalma at gmail dot com>
- To: Rich Felker <dalias at libc dot org>
- Cc: Roland McGrath <roland at hack dot frob dot com>, libc-alpha at sourceware dot org
- Date: Thu, 2 Oct 2014 09:12:13 +0200
- 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> <20140818192714 dot GS12888 at brightrain dot aerifal dot cx> <20141001211308 dot 88F742C397E at topped-with-meat dot com> <20141001211606 dot GN23797 at brightrain dot aerifal dot cx> <20141001213022 dot 798942C3AAD at topped-with-meat dot com> <20141002001720 dot GO23797 at brightrain dot aerifal dot cx>
Hi guys.
I'm working on a early implementation at the moment since I'm done
with my internship but I still have some doubts:
-How can I use pthread_* functions for my threads.h functions? I
guessed that would be including the pthread.h in threads.c but then we
cannot map objects between both in header file.
-Is it some pthread refactoring needed? I remember a time ago somebody
suggested that idea.
I have a small and dummy standalone implementation working, not
integrated in glibc code yet, but still have the issues that user can
call pthread functions from main so i guess some help would be
appreciated. I know these doubts are pretty simple but I'm some kind
of newbie and I'm trying to learn the best way to solve it.
Cheers.
2014-10-02 2:17 GMT+02:00 Rich Felker <dalias@libc.org>:
> On Wed, Oct 01, 2014 at 02:30:22PM -0700, Roland McGrath wrote:
>> > Thanks for the feedback. Since then we've got C11 threads support
>> > committed in musl, with the following definitions. Are these
>> > acceptable for glibc too? They're the same ones I proposed before.
>>
>> No guarantees until we actually implement something in glibc. But they
>> seem fine to me. The possible exception is that for interfaces where the
>> only valid thing is to pass in of the specified enum values, there is
>> something to be said for none of those values being zero (or -1) so that
>> applications can't sloppily use literal 0 (or uninitialized statics or the
>> like) and have it work but be non-portable and nonconforming.
>
> My motive for wanting success to have a value of 0 is that it allows
> some functions to be pure aliases or tail-calls where otherwise some
> heavier wrapping would be needed. Everyone expects success to be 0
> anyway. And since it's a return value, I don't think you'd have the
> issue of passing literal zeros.
>
> For mutex types, I suppose there's some risk of "sloppily" passing a
> literal 0 without meaning mtx_plain, but I think it's a small issue
> and I hope we can agree that keeping a common set of constants for ABI
> purposes is of more value.
>
> Rich
--
Juan Manuel "Lolo" Torres Palma.
Computer Science Student at Universidad de Granada.