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?