From e8d85034dad37177fce780ee3e09501e60be6e81 Mon Sep 17 00:00:00 2001 From: José Fonseca Date: Mon, 3 Mar 2014 14:55:41 +0000 Subject: mapi/u_thread: Use GetCurrentThreadId u_thread_self() expects thrd_current() to return a unique numeric ID for the current thread, but this is not feasible on Windows. Cc: "10.0" "10.1" Reviewed-by: Brian Paul --- src/mapi/u_thread.h | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) (limited to 'src/mapi/u_thread.h') diff --git a/src/mapi/u_thread.h b/src/mapi/u_thread.h index ba5d98ea902..3e183589c98 100644 --- a/src/mapi/u_thread.h +++ b/src/mapi/u_thread.h @@ -89,10 +89,28 @@ typedef mtx_t u_mutex; #define u_mutex_lock(name) (void) mtx_lock(&(name)) #define u_mutex_unlock(name) (void) mtx_unlock(&(name)) + static INLINE unsigned long u_thread_self(void) { + /* + * XXX: Callers of u_thread_self assume it is a lightweight function, + * returning a numeric value. But unfortunately C11's thrd_current() gives + * no such guarantees. In fact, it's pretty hard to have a compliant + * implementation of thrd_current() on Windows with such characteristics. + * So for now, we side-step this mess and use Windows thread primitives + * directly here. + * + * FIXME: On the other hand, u_thread_self() and _glthread_GetID() are bad + * abstractions. Even with pthreads, there is no guarantee that + * pthread_self() will return numeric IDs -- we should be using + * pthread_equal() instead of assuming we can compare thread ids... + */ +#ifdef _WIN32 + return GetCurrentThreadId(); +#else return (unsigned long) (uintptr_t) thrd_current(); +#endif } -- cgit v1.2.3