Bug 42254 – ThreadSpecific (QThreadStorage) should not be deleted

• Component: JavaScriptCore
• Status: RESOLVED FIXED

[Zoltan Herczeg]

Not sure this is the best thing, but something should be done with the annoying "QThreadStorage: Thread %p exited after QThreadStorage %d destroyed" messages.

QThreadStorageData::finish in http://qt.gitorious.org/qt/qt/blobs/4.7/src/corelib/thread/qthreadstorage.cpp

[Zoltan Herczeg]

Created attachment 61512 [details]
patch

[Zoltan Herczeg]

Any thoughts?

As I mentioned I am not sure this is the best soultion, but I would like to get rid of that annoying warning.

[Gavin Barraclough]

Looks right, but I'd like oliver to review.

[Oliver Hunt]

Comment on attachment 61512 [details]
patch

There is no requirement that the first client of JSC be a browser, nor that alternate threads be workers.  JSC has multiple mac clients that use jsc off the main thread, and CFNetwork uses JSC for PAC files, so 
"// This function surely called from the main thread first,"
Is incorrect.

If you really felt that this should be persistent you would either have to add a lock on stackGuards or push it into initializeThreading (or whatever that function is called).

That said I don't understand why Qt has a requirement that thread specific data not ever be removed -- this code seems to work with pthreads, and with windows' thread specific storage so i'm not sure why qt doesn't.

[Zoltan Herczeg]

I would prefer a write brarrier, but WTF does not support it :( (and AtomicIncrease is not supported by all platforms) A global lock would probably need a global constructor, and that is not preferred as well.

Qt is rather stupid in this case. The ThreadStorageData object has a destructor, which is called when the threads free their thread specific objects:

ThreadStorageData<T>::destroy(T*) { ... }

The destroy functions are registered in a list, and Qt require that the object exists, when the thread quit. This is somewhat stupid, since destroy could be a static function, which could free T without a 'this' argument. Perhaps they had problems with dynamically unloadable libraries, and decided that ThreadStorageData should never be destroyed. No idea.

Ok, I will find a different solution.

[Patrick R. Gansterer]

Since https://trac.webkit.org/changeset/101477 QThreadStorage isn't used any more.