ppedriana at gmail.com
Fri Aug 1 01:49:22 PDT 2008
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?
More information about the webkit-dev