ScriptArray is needed for serialized DOM access from WebInspector.
Created attachment 33513 [details] patch
Please do not land this. I'd like to land it myself so that it fit Chromium cycle nicely. Thanks.
M WebCore/WebCore.pro M WebCore/ChangeLog M WebCore/WebCore.vcproj/WebCore.vcproj M WebCore/GNUmakefile.am M WebCore/WebCore.gypi A WebCore/bindings/js/ScriptArray.h A WebCore/bindings/js/ScriptArray.cpp A WebCore/bindings/v8/ScriptArray.h A WebCore/bindings/v8/ScriptArray.cpp M WebCore/WebCore.xcodeproj/project.pbxproj r46410 = 0d0d5a3789c6238f7ebded1a26467e15dcb28fb5 (trunk)
Comment on attachment 33513 [details] patch Um, why are the JSC bindings use JSLock? Is ScriptArray meant to be called from a separate thread?
(In reply to comment #4) > (From update of attachment 33513 [details]) > Um, why are the JSC bindings use JSLock? Is ScriptArray meant to be called > from a separate thread? I copied them from the ScriptObject without much thinking. AFAIK we are not calling Script* from any other threads. Dmitry, do you know why locks are there?
Alexey Proskuryakov says the JSLock(flase) is just there to prevent the threading assertions and is a no-op. This patch is correct.