W3C home > Mailing lists > Public > public-device-apis-log@w3.org > September 2018

Re: [sensors] Garbage collection behavior unclear in Generic Sensor spec

From: Raphael Kubo da Costa via GitHub <sysbot+gh@w3.org>
Date: Fri, 21 Sep 2018 13:50:15 +0000
To: public-device-apis-log@w3.org
Message-ID: <issue_comment.created-423537306-1537537814-sysbot+gh@w3.org>
I agree that the "Sensor garbage collection" section only lists the situations where a `Sensor` object is not eligible for garbage collection -- with the consequence that in all other situations a `Sensor` object is just a regular JS object that follows the usual JS garbage collection rules. AFAICS those rules would not mark `a` in the snippet as eligible for collection between the call to `start()` and the setting of `onactivate` because there's a reference to the object as a local variable (`a` itself).

With that said, I think the wording in that section can be improved. I don't think implementations generally have a mechanism for being notified when an object is marked for garbage collection, but OTOH the original intent of that paragraph is to mention what needs to be done _when_ the object is GCed, at least according to #246 and #248.

> Therefore, we run the deactivation steps which returns the state to idle.
> Actually, that last step unclear to me. The test for "Deactivate a sensor object" does not say set the state to idle. However, (1) the diagram in "Sensor lifecycle" indicates to return to idle if activating does not complete successfully and (2) if a sensor has determined it going to be collected, what other state should it be in?

I read the "return to idle" part of the diagram as what we'd get in section 4.5 of Sensor.start() ("queue a task to run notify error [...]"); an object being marked as eligible for garbage collection is not an error IMO. As for (2), I thought the sensor's state would be irrelevant if it's going to be GC'ed.

> If a Sensor is in the activated state without an onreading handler, it is eligible for collection. Therefore, it must be deactivated. That all follows directly from the specification. It seems reasonable that a deactivated sensor does not generate new readings and consequently does not update the latest reading.

Does the bit about #246 and #248 also help solve this bit?

GitHub Notification of comment by rakuco
Please view or discuss this issue at https://github.com/w3c/sensors/issues/372#issuecomment-423537306 using your GitHub account
Received on Friday, 21 September 2018 13:50:16 UTC

This archive was generated by hypermail 2.3.1 : Friday, 21 September 2018 13:50:17 UTC