Bug 27691 - WebCore bindings: Implement ScriptArray bindings.
Summary: WebCore bindings: Implement ScriptArray bindings.
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebCore JavaScript (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Nobody
Depends on:
Reported: 2009-07-26 10:20 PDT by Pavel Feldman
Modified: 2009-07-27 13:11 PDT (History)
2 users (show)

See Also:

patch (20.97 KB, patch)
2009-07-26 11:15 PDT, Pavel Feldman
timothy: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Pavel Feldman 2009-07-26 10:20:24 PDT
ScriptArray is needed for serialized DOM access from WebInspector.
Comment 1 Pavel Feldman 2009-07-26 11:15:36 PDT
Created attachment 33513 [details]
Comment 2 Pavel Feldman 2009-07-26 11:52:07 PDT
Please do not land this. I'd like to land it myself so that it fit Chromium cycle nicely. Thanks.
Comment 3 Pavel Feldman 2009-07-27 02:07:47 PDT
	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 4 Oliver Hunt 2009-07-27 12:59:21 PDT
Comment on attachment 33513 [details]

Um, why are the JSC bindings use JSLock?  Is ScriptArray meant to be called from a separate thread?
Comment 5 Pavel Feldman 2009-07-27 13:05:39 PDT
(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?
Comment 6 Timothy Hatcher 2009-07-27 13:11:00 PDT
Alexey Proskuryakov says the JSLock(flase) is just there to prevent the threading assertions and is a no-op. This patch is correct.