Please note, this is a STATIC archive of website developer.mozilla.org from 03 Nov 2016, cach3.com does not collect or store any user information, there is no "phishing" involved.

JSObjectOps.dropProperty

Obsolete since JavaScript 1.8.5
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.

Warning: 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 for details.

The JSObjectOps.dropProperty callback releases a JSProperty.

Syntax

typedef void (*JSPropertyRefOp)(JSContext *cx, JSObject *obj, JSProperty *prop);
Name Type Description
cx JSContext * A context that was the cx argument to an earlier call to JSObjectOps.lookupProperty that found a property.
obj JSObject * The object of which prop is an own property.  That is, the value that the JSObjectOps.lookupProperty hook stored in the *objp out parameter.
prop JSProperty * The property to release. That is, the value that JSObjectOps.lookupProperty hook stored in the *propp out parameter.

Description

The following contract governs JSObjectOps callers and implementations:

  • Whenever JSObjectOps.lookupProperty returns a JSProperty pointer, the property is locked.
  • While the property is locked, the caller may access it using other 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.)
  • When finished with a locked property, the caller must release it by calling the dropProperty callback.
  • The lifetime of the 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. In SpiderMonkey 1.8 and earlier, the main built-in JSObjectOps implementation serialized all accesses to a given object's properties. (That is, for each object, all property accesses happened in some order, and what each thread observed was consistent with that order: no stale reads, for example.) However, SpiderMonkey does not guarantee this high degree of serialization.

Document Tags and Contributors

 Contributors to this page: arai, fscholz, tschneidereit, Jorend
 Last updated by: arai,