- From: Peter Hoddie via GitHub <sysbot+gh@w3.org>
- Date: Mon, 24 Sep 2018 19:25:37 +0000
- To: public-device-apis-log@w3.org
I suppose this matter hangs on the intended meaning of "eligible to garbage collect." The sensor implementation does not know if it is eligible to be garbage collected by the language. That is determined by running the garbage collector. The first two sections of 7.1.2 describe conditions when the sensor object "must not be garbage collected." That is unambiguous: the sensor implementation must prevent the object from being collected, even if the language rules allow it. The third section is less clear: > When a Sensor object whose [[state]] is "activated" or "activating" is eligible for garbage collection, the user agent must invoke deactivate a sensor object with this object as argument My reading is that when the sensor implementation should apply the preceding two rules using its current state and property values to determine if the instance "must not be garbage collected." If it may be garbage collected, then invoke deactivate. If I understand the comments above, the intent is perhaps simply the following: > When an Sensor object in the active state is garbage collected, it must invoke deactivate a sensor object with this object as the argument. A consequence of this behavior is that an active sensor object without `onreading` or `onerror` callbacks remains connected to the platform sensor until it is garbage collected. The script should call `stop`. Otherwise the connection to the platform sensor remains active until it is collected, consuming some resources unnecessarily for a non-deterministic period of time. -- GitHub Notification of comment by phoddie Please view or discuss this issue at https://github.com/w3c/sensors/issues/372#issuecomment-424095004 using your GitHub account
Received on Monday, 24 September 2018 19:25:39 UTC