This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: 2.26 release blockers?
On 05/07/2017 07:34, Joseph Myers wrote:
> On Wed, 5 Jul 2017, Siddhesh Poyarekar wrote:
>
>>> there's also the possibility of interactions with the thread types
>>> headers, if there's anything in the architecture-specific headers that
>>> works for pthreads but not for C11 threads.
>>
>> From a quick look at the changes, I couldn't find any changes in the
>> arch-specific sysdeps directories other than the abilist changes, i.e.
>> there are no architecture-specific headers. Bugs in C11 should thus be
>
> The thread types headers refactoring, to make them usable for both C11
> threads and pthreads, went in some time ago.
>
> All that architecture-specific header content will get used in C11 threads
> and it's far from obvious that any issues that appear with C11 threads
> would also appear with pthreads.
It was not clear to me if you still consider C11 threads patches a
disruptive for arch-testing that can't not get validated in current
cross-compiling testing.
I think the only snippet that differs significantly from pthread is
related to thread creation [1] where since different signatures between
POSIX and C11 I had to add an explicit cast and recast:
iff --git a/nptl/pthread_create.c b/nptl/pthread_create.c
index 7a970ff..3efb76d 100644
--- a/nptl/pthread_create.c
+++ b/nptl/pthread_create.c
@@ -461,7 +461,19 @@ START_THREAD_DEFN
LIBC_PROBE (pthread_start, 3, (pthread_t) pd, pd->start_routine, pd->arg);
/* Run the code the user provided. */
- THREAD_SETMEM (pd, result, pd->start_routine (pd->arg));
+ void *ret;
+ if (pd->c11)
+ {
+ /* The function pointer of the c11 thread start is cast to an incorrect
+ type on __pthread_create_2_1 call, however it is casted back to correct
+ one so the call behavior is well-defined (it is assumed that pointers
+ to void are able to represent all values of int. */
+ int (*start)(void*) = (int (*) (void*)) pd->start_routine;
+ ret = (void*) (intptr_t) start (pd->arg);
+ }
+ else
+ ret = pd->start_routine (pd->arg);
+ THREAD_SETMEM (pd, result, ret);
}
/* Call destructors for the thread_local TLS variables. */
Besides that, all other implementation uses pthread code directly and
with a validation of pthread primitives it should not show any
issues as you pointed out.
[1] https://sourceware.org/ml/libc-alpha/2017-06/msg01418.html