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

Justin Haygood jhaygood at reaktix.com
Fri Aug 1 12:34:53 PDT 2008

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

-----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

More information about the webkit-dev mailing list