Obsolete since JSAPI 30
This feature is obsolete. Although it may still work in some browsers, its use is discouraged since it could be removed at any time. Try to avoid using it.
This article covers features introduced in SpiderMonkey 1.8.5
JS_SetInterruptCallback, JS_GetInterruptCallback, JS_RequestInterruptCallback and JSInterruptCallback in SpiderMonkey 30.
void JS_SetOperationCallback(JSContext *cx, JSOperationCallback callback); JSOperationCallback JS_GetOperationCallback(JSContext *cx); void JS_TriggerOperationCallback(JSRuntime *rt);
JSBool (*JSOperationCallback)(JSContext *cx);
Pointer to a
Provides request. In
Applications must not use both the operation callback API and the older branch callback API.
These functions allow setting an operation callback that will be called from the JS thread some time after any thread triggered the callback using
To schedule the GC and for other activities the engine internally triggers operation callbacks. The embedding should thus not rely on callbacks being triggered through the external API only.
Important note: Additional callbacks can occur inside the callback handler if it re-enters the JS engine. The embedding must ensure that the callback is disconnected before attempting such re-entry.
JS_SetOperationCallback sets a callback that can be called asynchronously. Some common uses for an operation callback are:
- To run garbage collection periodically, by calling
- To periodically take a break from script execution to update the UI (though note that Mozilla does not do this, by design);
- To enforce application limits on the amount of time a script may run. (In this case, the callback may terminate the script by returning
JS_GetOperationCallback returns the currently installed operation callback, or
NULL if none is currently installed.
JS_TriggerOperationCallback triggers a callback set using
JS_GetOperationLimit returns the current operation limit, or