JS_NewGlobalObject 编辑
This article covers features introduced in SpiderMonkey 17
Create a new JavaScript object for use as a global object.
Syntax
JSObject *
JS_NewGlobalObject(JSContext *cx, const JSClass *clasp, JSPrincipals *principals,
JS::OnNewGlobalHookOption hookOption,
const JS::CompartmentOptions &options = JS::CompartmentOptions());
| Name | Type | Description |
|---|---|---|
cx | JSContext * | The context in which to create the new global object. Requires request. In a JS_THREADSAFE build, the caller must be in a request on this JSContext. |
clasp | Jsclass * | The class to use for the new global object.
JSClass remains alive throughout the lifetime of the new object, including the garbage collection cycle that finally frees it. The usual way to do this is to make JSClasses global or static. |
| principals | JSPrincipals * | The security information to associate with this compartment. |
| hookOption | JS::OnNewGlobalHookOption | See Debugger API Hook Added in SpiderMonkey 31 |
| options | const JS::CompartmentOptions & | The option for new compartment (passed to JScompartment constructor). Added in SpiderMonkey 31 |
Description
JS_NewGlobalObject creates a new global object based on the specified class.
The new object has no parent. It initially has no prototype either, since it is typically the first object created; call JS_InitStandardClasses to create all the standard objects, including Object.prototype, and set the global object's prototype.
The constructor clasp->construct is not called.
On success, JS_NewGlobalObject returns a pointer to the new object. Otherwise it returns NULL.
Debugger API Hook
During global creation, we fire notifications to callbacks registered via the Debugger API. These callbacks are arbitrary script, and can touch the global in arbitrary ways. When that happens, the global should not be in a half-baked state. But this creates a problem for consumers that need to set slots on the global to put it in a consistent state.
This API provides a way for consumers to set slots atomically (immediately after the global is created), before any debugger hooks are fired. It's unfortunately on the clunky side, but that's the way the cookie crumbles.
If callers have no additional state on the global to set up, they may pass FireOnNewGlobalHook to JS_NewGlobalObject, which causes that function to fire the hook as its final act before returning. Otherwise, callers should pass DontFireOnNewGlobalHook, which means that they are responsible for invoking JS_FireOnNewGlobalObject upon successfully creating the global. If an error occurs and the operation aborts, callers should skip firing the hook. But otherwise, callers must take care to fire the hook exactly once before compiling any script in the global's scope (we have assertions in place to enforce this). This lets us be sure that debugger clients never miss breakpoints.
enum OnNewGlobalHookOption {
FireOnNewGlobalHook,
DontFireOnNewGlobalHook
};
See Also
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论