Changeset 39708 in webkit

Timestamp:

Jan 8, 2009 8:47:14 AM (15 years ago)

Author:

ap@webkit.org

Message:

2009-01-08 Jian Li <​jianli@chromium.org>

Reviewed by Alexey Proskuryakov.

Add Win32 implementation of ThreadSpecific.
​https://bugs.webkit.org/show_bug.cgi?id=22614

• JavaScriptCore.vcproj/WTF/WTF.vcproj:
• wtf/ThreadSpecific.h: (WTF::ThreadSpecific::ThreadSpecific): (WTF::ThreadSpecific::~ThreadSpecific): (WTF::ThreadSpecific::get): (WTF::ThreadSpecific::set): (WTF::ThreadSpecific::destroy):
• wtf/ThreadSpecificWin.cpp: Added. (WTF::ThreadSpecificThreadExit):
• wtf/ThreadingWin.cpp: (WTF::wtfThreadEntryPoint):

Location:

trunk/JavaScriptCore

Files:

• ChangeLog (modified) (1 diff)
• JavaScriptCore.vcproj/WTF/WTF.vcproj (modified) (3 diffs)
• wtf/ThreadSpecific.h (modified) (7 diffs)
• wtf/ThreadSpecificWin.cpp (added)
• wtf/ThreadingWin.cpp (modified) (2 diffs)

trunk/JavaScriptCore/ChangeLog

@@ +1 @@
+2009-01-08  Jian Li  <jianli@chromium.org>
+
+        Reviewed by Alexey Proskuryakov.
+
+        Add Win32 implementation of ThreadSpecific.
+        https://bugs.webkit.org/show_bug.cgi?id=22614
+
+        * JavaScriptCore.vcproj/WTF/WTF.vcproj:
+        * wtf/ThreadSpecific.h:
+        (WTF::ThreadSpecific::ThreadSpecific):
+        (WTF::ThreadSpecific::~ThreadSpecific):
+        (WTF::ThreadSpecific::get):
+        (WTF::ThreadSpecific::set):
+        (WTF::ThreadSpecific::destroy):
+        * wtf/ThreadSpecificWin.cpp: Added.
+        (WTF::ThreadSpecificThreadExit):
+        * wtf/ThreadingWin.cpp:
+        (WTF::wtfThreadEntryPoint):
+
 2009-01-08  Justin McPherson <justin.mcpherson@nokia.com>
 

trunk/JavaScriptCore/JavaScriptCore.vcproj/WTF/WTF.vcproj

@@ -1 @@
-<?xml version="1.0" encoding="Windows-1252"?>
+<?xml version="1.0" encoding="windows-1251"?>
 <VisualStudioProject
         ProjectType="Visual C++"
-        Version="8.00"
+        Version="8,00"
         Name="WTF"
         ProjectGUID="{AA8A5A85-592B-4357-BC60-E0E91E026AF6}"
@@ -420 +420 @@
                 </File>
                 <File
+                        RelativePath="..\..\wtf\Threading.cpp"
+                        >
+                </File>
+                <File
                         RelativePath="..\..\wtf\Threading.h"
                         >
                 </File>
                 <File
-                        RelativePath="..\..\wtf\Threading.cpp"
-                        >
-                </File>
-                <File
                         RelativePath="..\..\wtf\ThreadingWin.cpp"
                         >
@@ -433 +433 @@
                 <File
                         RelativePath="..\..\wtf\ThreadSpecific.h"
+                        >
+                </File>
+                <File
+                        RelativePath="..\..\wtf\ThreadSpecificWin.cpp"
                         >
                 </File>

trunk/JavaScriptCore/wtf/ThreadSpecific.h

@@ -1 +1 @@
 /*
  * Copyright (C) 2008 Apple Inc. All rights reserved.
+ * Copyright (C) 2009 Jian Li <jianli@chromium.org>
  *
  * Redistribution and use in source and binary forms, with or without
@@ -27 +28 @@
  */
 
+/* Thread local storage is implemented by using either pthread API or Windows
+ * native API. There is subtle semantic discrepancy for the cleanup function
+ * implementation as noted below:
+ *   @ In pthread implementation, the destructor function will be called
+ *     repeatedly if there is still non-NULL value associated with the function.
+ *   @ In Windows native implementation, the destructor function will be called
+ *     only once.
+ * This semantic discrepancy does not impose any problem because nowhere in
+ * WebKit the repeated call bahavior is utilized.
+ */
+
 #ifndef WTF_ThreadSpecific_h
 #define WTF_ThreadSpecific_h
@@ -32 +44 @@
 #include <wtf/Noncopyable.h>
 
-#if USE(PTHREADS) || PLATFORM(WIN)
-// Windows currently doesn't use pthreads for basic threading, but implementing destructor functions is easier
-// with pthreads, so we use it here.
+#if USE(PTHREADS)
 #include <pthread.h>
+#elif PLATFORM(WIN_OS)
+#include <windows.h>
 #endif
 
 namespace WTF {
+
+#if !USE(PTHREADS) && PLATFORM(WIN_OS)
+// ThreadSpecificThreadExit should be called each time when a thread is detached.
+// This is done automatically for threads created with WTF::createThread.
+void ThreadSpecificThreadExit();
+#endif
 
 template<typename T> class ThreadSpecific : Noncopyable {
@@ -49 +67 @@
 
 private:
+#if !USE(PTHREADS) && PLATFORM(WIN_OS)
+    friend void ThreadSpecificThreadExit();
+#endif
+    
     T* get();
     void set(T*);
     void static destroy(void* ptr);
 
-#if USE(PTHREADS) || PLATFORM(WIN)
+#if USE(PTHREADS) || PLATFORM(WIN_OS)
     struct Data : Noncopyable {
         Data(T* value, ThreadSpecific<T>* owner) : value(value), owner(owner) {}
@@ -59 +81 @@
         T* value;
         ThreadSpecific<T>* owner;
+#if !USE(PTHREADS)
+        void (*destructor)(void*);
+#endif
     };
-
+#endif
+
+#if USE(PTHREADS)
     pthread_key_t m_key;
+#elif PLATFORM(WIN_OS)
+    int m_index;
 #endif
 };
 
-#if USE(PTHREADS) || PLATFORM(WIN)
+#if USE(PTHREADS)
 template<typename T>
 inline ThreadSpecific<T>::ThreadSpecific()
@@ -94 +123 @@
 }
 
+#elif PLATFORM(WIN_OS)
+
+// The maximum number of TLS keys that can be created. For simplification, we assume that:
+// 1) Once the instance of ThreadSpecific<> is created, it will not be destructed until the program dies.
+// 2) We do not need to hold many instances of ThreadSpecific<> data. This fixed number should be far enough.
+const int kMaxTlsKeySize = 256;
+
+extern long g_tls_key_count;
+extern DWORD g_tls_keys[kMaxTlsKeySize];
+
+template<typename T>
+inline ThreadSpecific<T>::ThreadSpecific()
+    : m_index(-1)
+{
+    DWORD tls_key = TlsAlloc();
+    if (tls_key == TLS_OUT_OF_INDEXES)
+        CRASH();
+
+    m_index = InterlockedIncrement(&g_tls_key_count) - 1;
+    if (m_index >= kMaxTlsKeySize)
+        CRASH();
+    g_tls_keys[m_index] = tls_key;
+}
+
+template<typename T>
+inline ThreadSpecific<T>::~ThreadSpecific()
+{
+    // Does not invoke destructor functions. They will be called from ThreadSpecificThreadExit when the thread is detached.
+    TlsFree(g_tls_keys[m_index]);
+}
+
+template<typename T>
+inline T* ThreadSpecific<T>::get()
+{
+    Data* data = static_cast<Data*>(TlsGetValue(g_tls_keys[m_index]));
+    return data ? data->value : 0;
+}
+
+template<typename T>
+inline void ThreadSpecific<T>::set(T* ptr)
+{
+    ASSERT(!get());
+    Data* data = new Data(ptr, this);
+    data->destructor = &ThreadSpecific<T>::destroy;
+    TlsSetValue(g_tls_keys[m_index], data);
+}
+
+#else
+#error ThreadSpecific is not implemented for this platform.
+#endif
+
 template<typename T>
 inline void ThreadSpecific<T>::destroy(void* ptr)
@@ -99 +179 @@
     Data* data = static_cast<Data*>(ptr);
 
+#if USE(PTHREADS)
     // We want get() to keep working while data destructor works, because it can be called indirectly by the destructor.
     // Some pthreads implementations zero out the pointer before calling destroy(), so we temporarily reset it.
     pthread_setspecific(data->owner->m_key, ptr);
+#endif
+    
     data->value->~T();
     fastFree(data->value);
+
+#if USE(PTHREADS)
     pthread_setspecific(data->owner->m_key, 0);
-    delete data;
-}
-
+#elif PLATFORM(WIN_OS)
+    TlsSetValue(g_tls_keys[data->owner->m_index], 0);
 #else
 #error ThreadSpecific is not implemented for this platform.
 #endif
+
+    delete data;
+}
 
 template<typename T>

trunk/JavaScriptCore/wtf/ThreadingWin.cpp

@@ -65 +65 @@
 
 #include "MainThread.h"
+#if !USE(PTHREADS) && PLATFORM(WIN_OS)
+#include "ThreadSpecific.h"
+#endif
 #include <process.h>
 #include <windows.h>
@@ -175 +178 @@
 
     void* result = invocation.function(invocation.data);
+
+#if !USE(PTHREADS) && PLATFORM(WIN_OS)
+    // Do the TLS cleanup.
+    ThreadSpecificThreadExit();
+#endif
 
     return reinterpret_cast<unsigned>(result);