Checking in Feng Qian's <feng.qian.moz@gmail.com> patch to make XPConnect eagerly attach its thread private data before the JS engine does, ensuring good ordering when the thread (and thus both XPConnect on that thread and the JS runtime) shuts down, thus preventing racing and use of deleted memory. bug 335018, r=brendan

git-svn-id: svn://10.0.0.236/trunk@205079 18797224-902f-48f8-a5cc-f745e15eee43
This commit is contained in:
mrbkap%gmail.com 2006-07-28 20:25:39 +00:00
parent 6f4cbeded7
commit cb96c19e77

View File

@ -137,6 +137,23 @@ nsJSRuntimeServiceImpl::GetRuntime(JSRuntime **runtime)
if(!mRuntime)
{
// Call XPCPerThreadData::GetData to initialize
// XPCPerThreadData::gTLSIndex before initializing
// JSRuntime::threadTPIndex in JS_NewRuntime.
//
// XPConnect uses a thread local storage (XPCPerThreadData) indexed by
// XPCPerThreadData::gTLSIndex, and SpiderMonkey GC uses a thread local
// storage indexed by JSRuntime::threadTPIndex.
//
// The destructor for XPCPerThreadData::gTLSIndex may access
// thread local storage indexed by JSRuntime::threadTPIndex.
// Thus, the destructor for JSRuntime::threadTPIndex must be called
// later than the one for XPCPerThreadData::gTLSIndex.
//
// We rely on the implementation of NSPR that calls destructors at
// the same order of calling PR_NewThreadPrivateIndex.
XPCPerThreadData::GetData();
mRuntime = JS_NewRuntime(gGCSize);
if(!mRuntime)
return NS_ERROR_OUT_OF_MEMORY;