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

[Justin Haygood]

What benefits does using pthreads on win32 have over the native primitives?
If you linked in pthreads statically, there's less of an issue, but the more
DLLs you have = bad for the most part (this is why Firefox statically links
in most of their libraries). Even then, the pthreads-win32 barely covers any
of the pthread functionality above and beyond "create a thread and run it",
since it depends heavily on some Unix-isms.

Personally, I vote with sticking with ThreadingWin.cpp, since it introduces
less complexity (less libraries to deal with, thin wrapper around the OS
primitives, no need to depend on the quality of a third party library that
barely covers any of the functionality of the lib its supposed to
implement).

-----Original Message-----
From: Alexey Proskuryakov [mailto:ap at webkit.org] 
Sent: Friday, August 01, 2008 5:31 AM
To: Paul Pedriana
Cc: Justin Haygood; webkit-dev at lists.webkit.org
Subject: Re: [webkit-dev] [webkit-changes] [35474] trunk/JavaScriptCore


On Aug 1, 2008, at 12:49 PM, Paul Pedriana wrote:

> It would constitute a bit of code duplication if our Windows apps  
> linked both EAThread and pthreads. Instead it would be better if we  
> just made a small inline shim between the pthread interface and  
> EAThread, so any pthreads calls would be just inline redirections to  
> EAThread.


Well, I guess that in such case, there is little point in using  
pthreads API, and you'd be better served with ThreadingEA.cpp?

All port authors who spoke prefer (to a different degree) their own  
WebKit-specific threading implementations to using pthreads. Hard to  
argue with that, even though I still dislike the idea for the reasons  
stated earlier.

I think I'd like to eventually move Apple's Windows port from  
ThreadingWin to ThreadingPthreads anyway, but that's a separate topic  
for discussion.

- WBR, Alexey Proskuryakov