Obsolete since JSAPI 13
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.
Register a custom string memory manager.
Syntax
int JS_AddExternalStringFinalizer(JSStringFinalizeOp finalizer);
| Name | Type | Description |
|---|---|---|
finalizer |
JSStringFinalizeOp |
Pointer to a callback function, described below. The JS engine will automatically call this function each time a string created by JS_NewExternalString is garbage-collected. |
Callback syntax
typedef void (*JSStringFinalizeOp)(JSContext *cx, JSString *str);
| Name | Type | Description |
|---|---|---|
cx |
JSContext * |
Pointer to a JSContext which the finalizer may use for certain very limited operations (not documented). Since the JSStringFinalizeOp callback is called during garbage collection, it must avoid most JSAPI functions. (Is cx guaranteed to be non-NULL?) |
str |
JSString * |
The string being finalized. This is always a string that the application previously created by calling JS_NewExternalString. The callback may use JS_NewExternalString() when creating the string. It is the callback's responsibility to free the memory. After this callback, the JS engine will not use that memory anymore and will not keep a pointer to it.
The callback may not keep a reference to this |
Description
Add a finalizer for external strings created by JS_NewExternalString using a type-code returned from this function, and that understands how to free or release the memory pointed at by JS_GetStringChars(str)
Returns a nonnegative type index if there is room for finalizer in the global GC finalizers table, else returns -1. In a JS_THREADSAFE build, this function must be invoked on the primordial thread only, at startup—or else the entire program must single-thread itself while loading a module that calls this function.
To remove an external string finalizer, use JS_RemoveExternalStringFinalizer.