[Mesa-dev] [PATCH 2/3] mapi/u_thread: Use GetCurrentThreadId

jfonseca at vmware.com jfonseca at vmware.com
Mon Mar 3 13:41:07 PST 2014


From: José Fonseca <jfonseca at vmware.com>

u_thread_self() expects thrd_current() to return a unique numeric ID
for the current thread, but this is not feasible on Windows.
---
 src/mapi/u_thread.h | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/src/mapi/u_thread.h b/src/mapi/u_thread.h
index ba5d98e..3e18358 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
 }
 
 
-- 
1.8.5.3



More information about the mesa-dev mailing list