mapi/u_thread: Use GetCurrentThreadId
authorJosé Fonseca <jfonseca@vmware.com>
Mon, 3 Mar 2014 14:55:41 +0000 (14:55 +0000)
committerJosé Fonseca <jfonseca@vmware.com>
Tue, 4 Mar 2014 12:05:23 +0000 (12:05 +0000)
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" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
src/mapi/u_thread.h

index ba5d98ea902bf0549b2bc04a1193c05c1d0462cf..3e183589c98263973ffe50a8e201691719326a85 100644 (file)
@@ -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
 }