Finalization is an expensive option with no promptness guarantees. If a
manager is not guaranteed to be closed are their any downsides?

On Mon, Aug 17, 2015 at 2:41 PM, Burcu Dogan notifications@github.com
wrote:

Users are required to explicitly close the Manager by invoking
(*Manager).Close, but the same action could be handled during finalization
without user having to explicitly call Close.

—
Reply to this email directly or view it on GitHub
#12169.

Rick, Burcu, can't we support both methods for closing?
I think that is the case for various Java libraries managing files -- it's
better to call Close in a timely fashion, but failing that, a finalizer
(eventually) plugs the descriptor leak.
We might additionally want the finalizer-Close to collect some sort of
statistics about its use in case there are related performance issues.

On Mon, Aug 17, 2015 at 3:08 PM, Richard L. Hudson <notifications@github.com

wrote:

Finalization is an expensive option with no promptness guarantees. If a
manager is not guaranteed to be closed are their any downsides?

On Mon, Aug 17, 2015 at 2:41 PM, Burcu Dogan notifications@github.com
wrote:

Users are required to explicitly close the Manager by invoking
(*Manager).Close, but the same action could be handled during
finalization
without user having to explicitly call Close.

—
Reply to this email directly or view it on GitHub
#12169.

—
Reply to this email directly or view it on GitHub
#12169 (comment).

The downside is the memory leak. Each sensor.Manager allocates several underlying resources.

We debated finalization vs Closer interface a couple of times in different contexts for the mobile project. In this particular case, I would prefer not to implement io.Closer because it is fine not to have a guarantee -- the leak is not expensive. The only concern is the unexpected finalizations as it was the case at #10636. sensor.Manager instances are likely to be long-living, similar to al.Context.

Designing an API where a piece of code may or may not run and if it does it
will run at a non-deterministic time has always led me to pain.

Currently (1.5) managing finalization happens during the stop the world
mark termination phase of the GC. A large part of the remaining latency in
1.5 is related to dealing with finalization. We will be able to move leaf
object that need to be finalize out of the stop the world part of the GC
into the sweep phase. Objects containing pointers will be more difficult
but mostly doable in the 1.6 timeframe. And yes we have customers with use
cases that are being hit by this so we are motivated.

Offering both seems reasonable, if the memory being leaked becomes a bigger
problem than using finalization then one can use the finalizer backed API.

On Mon, Aug 17, 2015 at 3:28 PM, Burcu Dogan notifications@github.com
wrote:

The downside is the memory leak. Each sensor.Manager allocates several
underlying resources.

We debated finalization vs Closer interface a couple of times in different
contexts for the mobile project. In this particular case, I would prefer
not to implement io.Closer because it is fine not to have a guarantee --
the leak is not expensive. The only concern is the unexpected finalizations
as it was the case at #10636 #10636.
sensor.Manager instances are likely to be long-living, similar to
al.Context.

—
Reply to this email directly or view it on GitHub
#12169 (comment).

We are planning to move to a new design where we won't allow multiple instances of Manager. Given the feedback, if we have to reconsider the previous APIs, I am going to be offering a finalizer as an addition to Close. Closing the issue due to obsoleteness.