Core design: Script Execution

Owner: Jens Lindström
Co-owner: Lars T Hansen

Author: Lars T Hansen
Date written: 2004-09-30
Reviewer: Jens Lindström
Date reviewed: (not yet reviewed)
Architecture group reviewer: (not yet reviewed)
Date reviewed: (not yet reviewed)

Scope

This document covers the mechanism of script execution proper, from the moment a script's source code has been received and identified to the moment when the result of the script is handed to the agent that has requested the script's execution and the script is destroyed.

Related designs (and how they are related)

Document Parsing
Script source code is extracted from the document code or supplied by external agents or connected as event handlers to elements of the document tree.
Event Handling
Event handling in the document tree: event handlers are scripts
Proxy Determination
Scripts are used for the Automatic Proxy Configuration by JavaScript functionality.
Script Environments
The various kinds of environments that scripts may run in, and how they are created and destroyed.

The design

Programs and functions

Scripts appear in two flavors, as programs and functions. Inline scripts and linked scripts are always programs. Event handlers are always functions. The difference between a program and a function is primarily that the latter allows a return statement to appear on the top level; executing such a return statement causes evaluation to terminate. Furthermore, programs often contain initialization actions that must only be run once, so it is rarely natural to run the same program multiple times. Functions are routinely run multiple times, however.

...

Compiling scripts

Scripts must always be compiled before they can be run. ...

Running scripts asynchronously

Scripts are normally run asynchronously by creating a script execution thread which is then handed off to the scheduler for later execution. When the execution is finished, listeners on the thread will be notified of the completion. ...

Creating threads; thread types

...

Scheduling a thread

...

Listening for thread events

...

Note about how threads are scheduled, interrupted, and cancelled

...

Running scripts synchronously

For special purposes it is sometimes desirable to run scripts synchronously. (Normally you really do not want to do this, so think carefully.) To do this, you need to create an execution context for the script and run the script engine directly, bypassing the normal scheduler.

...

The autoproxy module uses synchronous script execution (but incorporates a time limit to prevent endless loops from hanging Opera). See the description of the Proxy Determination design.

Destroying scripts

Compiled scripts must be destroyed explicitly when they are no longer used. ...

Modules affected

The ECMAScript scheduler is defined in the module ecmascript_utils and the ECMAScript engine is defined in the module ecmascript. The logdoc module calls the engine to compile scripts, while the doc module calls the scheduler to handle events. The autoproxy and java modules both call the ecmascript module to compile and run scripts.

... (Async interface; and does the Java module use the scheduler?)

Critique and history

The current design is the second generation and was introduced in Opera 7. It came about as a result of the old design's inability to mimic the scheduler semantics of MSIE and Mozilla (neither of which has timeslicing) and the difficulty of dealing with blocking and suspension in that scheduler.

...

Revision History

2004-09-30 / lth: Early draft