Re: [webkit-dev] [webkit-changes] [35474] trunk/JavaScriptCore
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
We already do maintain it... WebCore uses it quite heavily. Why not use it? It uses the platform's native threading APIs (gthread on glib, QThread on Qt, pthread on OS X, Win32 threads on Win32)
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
-- Justin Haygood jhaygood@reaktix.com Reaktix. Reality Redefined.
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
On Aug 1, 2008, at 3:39 AM, Paul Pedriana wrote:
Actually, even under Windows we'd probably still use an emulated pthreads if possible instead of pthreads.dll, as the pthreads.dll for Windows does a lot of things that are typically not needed and increases the footprint more than we'd like
That's very interesting - could you tell more about this?
>> But with pthreads, we get well tested implementations for many platforms
I wonder if somebody has a list of platforms that pthreads exists for and is well-tested on. I'm not aware of it existing much outside of *nix, Mac, and Windows. I'm not saying this to argue against it, though I am wondering how common pthreads really is.
I believe Symbian has pthreads, too. I have not seen an extensive list, though. - WBR, Alexey Proskuryakov
Well we already have a cross-platform threading interface/implementation. It is conceptually similar to pthreads (but also includes things like portable atomics) but is C++ and is tailored to functionality useful to us and which exists on our target platforms (primarily XBox 360, PS3, PS2, Wii, Win32, Win64, OS X, Linux32, Linux64). Most EA games on these platforms use this package (which is called, unsurprisingly, EAThread). 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. This would probably work fine as long as some of the more esoteric features of pthreads weren't depended on, as I mentioned previously. There are other benefits to having your own threading library, such as enhanced diagnostics and debugging, but that's another topic of discussion. Regarding my comment about address space, a number of PC games these days are starting to run into address space problems. For example, we are about to release Spore, and there are documented address space problems such as mentioned here: http://www.spore.com/what/specs_spore. Windows gives apps two GB of address space, but that space gets eaten up but the large amount of memory that PC games often use and the mapped code and data segments for all the DLLs that get loaded with applications.
Actually, even under Windows we'd probably still use an emulated pthreads if possible instead of pthreads.dll, as the pthreads.dll for Windows does a lot of things that are typically not needed and increases the footprint more than we'd like That's very interesting - could you tell more about this?
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
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@webkit.org] 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
participants (3)
-
Alexey Proskuryakov
-
Justin Haygood
-
Paul Pedriana