[webkit-dev] [webkit-changes] [35474] trunk/JavaScriptCore

[Alexey Proskuryakov]

On Jul 31, 2008, at 11:40 PM, Justin Haygood wrote:

>> Well, what I'm saying is that maintaining our own abstraction layer  
>> is
>> a large and unnecessary burden.
>>
> We already do maintain it... WebCore uses it quite heavily. Why not  
> use it?


Right now, the abstraction is weaker than needed by JSC, and hasn't  
been scrutinized for interoperability in non-trivial cases (e.g.  
WebCore threads never die, so we didn't need to define and  
interoperably implement the behavior of synchronization primitives in  
this case).

Obviously, the suggestion to more fully embrace pthreads involves  
removing other implementations from Threading*.cpp eventually, so that  
we wouldn't need to maintain this code.

> It uses the platform's native threading APIs (gthread on glib,  
> QThread on Qt, pthread on OS X, Win32 threads on Win32)

Naturally, pthreads also uses native threading APIs on each platform  
(even more native, as it does not go through Qt/gtk wrappers, which  
may become important for performance and correctness). But with  
pthreads, we get well tested implementations for many platforms, with  
an API that is documented in man pages, books etc.

Are there any benefits in redoing all this work? As Brent wrote, not  
having to include pthreads.dll is beneficial, but I do not see why one  
couldn't statically link pthreads, if needed.

- WBR, Alexey Proskuryakov