Re: [webkit-dev] [webkit-changes] [35474] trunk/JavaScriptCore
On Jul 31, 2008, at 10:38 AM, eric@webkit.org wrote:
Try to clean up our usage of USE(MULTIPLE_THREADS) vs. USE(PTHREADS) a little.
There is indeed some confusion between MULTIPLE_THREADS and PTHREADS in JSC now. One of the reasons is that some of the threading code can be used in WebCore even if JSC is not threaded, and vice versa. The former macro enables JSC multithreading, while the latter in not as clear cut.
It looks like JSC assumes that if MULTIPLE_THREADS is defined, then pthreads will always be available I'm not sure that's always the case for gtk, certainly not for Windows. We should eventually go back and fix wtf/Threading.h to cover all these cases some day.
Yes, JSC currently assumes that pthreads is available for MULTIPLE_THREADS. It is not at all obvious to me that this is a wrong assumption - we'd need a compatibility layer for platforms that don't have native pthreads anyway, so why not use existing pthreads implementations for these platforms? We do that on Windows, for example. Let's discuss this before declaring it wrong at least.
Modified: trunk/JavaScriptCore/kjs/collector.h (35473 => 35474) --- trunk/JavaScriptCore/kjs/collector.h 2008-07-31 06:14:13 UTC (rev 35473) +++ trunk/JavaScriptCore/kjs/collector.h 2008-07-31 06:38:54 UTC (rev 35474) @@ -28,9 +28,6 @@ #include <wtf/Noncopyable.h> #include <wtf/OwnPtr.h> #include <wtf/Threading.h> -#if USE(MULTIPLE_THREADS) -#include <pthread.h> -#endif
This change in particular seems wrong to me - the file uses pthread_key_t under #if USE(MULTIPLE_THREADS), but pthread.h is only included in Threading.h under #if USE(PTHREADS). - WBR, Alexey Proskuryakov
I think it's wrong for JSC to assume pthreads. Gtk seems to have its own threading system. Windows does too. It's unclear to me (aside from the comment below) why it needs them long term.
From wtf/ThreadingWin.cpp (why is this not in wtf/win/?)
#if PLATFORM(WIN) // Currently, Apple's Windows port uses a mixture of native and pthreads functions in FastMalloc. // To ensure that thread-specific data is properly destroyed, we need to end each thread with pthread_exit(). #include <pthread.h> #endif -eric On Thu, Jul 31, 2008 at 1:08 AM, Alexey Proskuryakov <ap@webkit.org> wrote:
On Jul 31, 2008, at 10:38 AM, eric@webkit.org wrote:
Try to clean up our usage of USE(MULTIPLE_THREADS) vs. USE(PTHREADS) a little.
There is indeed some confusion between MULTIPLE_THREADS and PTHREADS in JSC now. One of the reasons is that some of the threading code can be used in WebCore even if JSC is not threaded, and vice versa. The former macro enables JSC multithreading, while the latter in not as clear cut.
It looks like JSC assumes that if MULTIPLE_THREADS is defined, then pthreads will always be available I'm not sure that's always the case for gtk, certainly not for Windows. We should eventually go back and fix wtf/Threading.h to cover all these cases some day.
Yes, JSC currently assumes that pthreads is available for MULTIPLE_THREADS. It is not at all obvious to me that this is a wrong assumption - we'd need a compatibility layer for platforms that don't have native pthreads anyway, so why not use existing pthreads implementations for these platforms? We do that on Windows, for example. Let's discuss this before declaring it wrong at least.
Modified: trunk/JavaScriptCore/kjs/collector.h (35473 => 35474)
--- trunk/JavaScriptCore/kjs/collector.h 2008-07-31 06:14:13 UTC (rev 35473) +++ trunk/JavaScriptCore/kjs/collector.h 2008-07-31 06:38:54 UTC (rev 35474) @@ -28,9 +28,6 @@ #include <wtf/Noncopyable.h> #include <wtf/OwnPtr.h> #include <wtf/Threading.h> -#if USE(MULTIPLE_THREADS) -#include <pthread.h> -#endif
This change in particular seems wrong to me - the file uses pthread_key_t under #if USE(MULTIPLE_THREADS), but pthread.h is only included in Threading.h under #if USE(PTHREADS). - WBR, Alexey Proskuryakov
On Jul 31, 2008, at 12:58 PM, Eric Seidel wrote:
I think it's wrong for JSC to assume pthreads. Gtk seems to have its own threading system. Windows does too. It's unclear to me (aside from the comment below) why it needs them long term.
Any custom solution that we may come up with will be quite heavyweight - it is not correct to assume that WTF::Mutex can just call through to a mutex (or critical section) provided by the platform, for example, as the semantics differ a lot. We'd basically need to take pthreads implementations for all platforms and import those into WTF, possibly changing the coding style. Yes, I'm exaggerating, but not too much :) Now, what's the benefit of importing pthreads into WTF compared to using it as an external library? - WBR, Alexey Proskuryakov
On Jul 31, 2008, at 1:11 PM, Alexey Proskuryakov wrote:
We'd basically need to take pthreads implementations for all platforms
Or we could take the code from another existing library - e.g., ThreadingWin uses code from Boost. Again, the benefits are not obvious to me. - WBR, Alexey Proskuryakov
On Thu, Jul 31, 2008 at 2:31 AM, Alexey Proskuryakov <ap@webkit.org> wrote:
We'd basically need to take pthreads implementations for all platforms
Or we could take the code from another existing library - e.g., ThreadingWin uses code from Boost. Again, the benefits are not obvious to me.
One benefit to using the native thread primitives on each platform is that it reduces the need to include things like pthreads.dll in the distribution. For embedded/cell phone use, this is a benefit. Since WebKit has its own threading abstraction layer, I think it is unwise for code outside this layer to make use of the special knowledge that pthreads is in use. Whatever you want to be doing via calls to pthreads primitives should instead be handled using one of the WTF/Thread methods. If no such method exists, it should be added so that proper variants for the specific platforms are used. -Brent
On Jul 31, 2008, at 11:30 PM, Brent Fulgham wrote:
Since WebKit has its own threading abstraction layer, I think it is unwise for code outside this layer to make use of the special knowledge that pthreads is in use. Whatever you want to be doing via calls to pthreads primitives should instead be handled using one of the WTF/Thread methods. If no such method exists, it should be added so that proper variants for the specific platforms are used.
Well, what I'm saying is that maintaining our own abstraction layer is a large and unnecessary burden. - WBR, Alexey Proskuryakov
participants (3)
-
Alexey Proskuryakov
-
Brent Fulgham
-
Eric Seidel