
JSObjectOps is not a supported API. Details of the API may change from one release to the next. This documentation should be considered SpiderMonkey internals documentation, not API documentation. See
bug 408416
.
The JSObjectOps.dropProperty callback releases a JSProperty.
typedef void (*JSPropertyRefOp)(JSContext *cx, JSObject *obj, JSProperty *prop);
| Name | Type | Description |
|---|---|---|
cx |
JSContext * |
The context in which the JSProperty pointer prop was obtained (by calling JSObjectOps.defineProperty or JSObjectOps.lookupProperty). |
obj |
JSObject * |
The object from which the prop was obtained. |
prop |
JSProperty * |
The property to release. |
The following contract governs JSObjectOps callers and implementations:
JSObjectOps.defineProperty or JSObjectOps.lookupProperty returns a JSProperty pointer, the property is locked. If defineProperty is called with a null pprop out parameter, the new property is not locked.
JSObjectOps callbacks. It may not otherwise call into the JSAPI in ways that might trigger other property accesses. (In a JS_THREADSAFE build, that would risk deadlock.)
dropProperty callback.
JSProperty * extends from the successful defineProperty or lookupProperty call to the dropProperty call.
As a SpiderMonkey implementation detail, what is actually locked here (under the native implementation of JSObjectOps) is not the property but some collection of objects including the object on which the property is defined. The granularity of the locking is up to the JSObjectOps implementation; deadlock does not happen because each thread accesses only one property at a time.
A single, built-in JSObjectOps implementation is used for most SpiderMonkey objects that are exposed to scripts. Custom JSObjectOps implementations can either retain the SpiderMonkey property storage and locking scheme (by copying all or most of the built-in JSObjectOps) or replace it entirely.
Threads. In a JS_THREADSAFE build, any consistency observed by multiple threads operating on the same data is provided solely by the property locking scheme described above. Currently, the main built-in JSObjectOps implementation serializes all accesses to a given object's properties. (That is, for each object, all property accesses happen in some order, and what each thread observes is consistent with that order: no stale reads, for example.) However, SpiderMonkey does not guarantee this high degree of serialization.
Page last modified 17:00, 3 Jul 2008 by Jorend