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:[EMAIL PROTECTED] Sent: Friday, August 01, 2008 5:31 AM To: Paul Pedriana Cc: Justin Haygood; webkit-dev@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 _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
