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

[Paul Pedriana]

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?