Re: [go-nuts] Re: What are finalizers missing?

[Robert Engels]

You should always use an explicit Close() - a Close() performed by a finalizer should only be use to simplify the case of a shared resource that would typically involve manual reference counting (which is very susceptible to bugs - especially in a concurrent environment).

If you have a highly concurrent environment with lots of shared files (enough to run out of resources), you probably need explicit resource management.

-----Original Message-----
From: Tyler Compton
Sent: Feb 18, 2020 11:29 AM
To: Jake Montgomery
Cc: golang-nuts
Subject: Re: [go-nuts] Re: What are finalizers missing?

Good point, I had forgotten about the 2 minute rule the GC has.

So it's not a matter of  the go runtime not knowing "which Go objects it can finalize in order to get that [a resource] back", its simply a matter of the variable pace of GC. In theory GC can happen as infrequently as every 2 minutes. So if you are ok with you non-Go resource lingering for that long, then use finalizers. In most cases that is not sufficient though.

I think you're touching on the point I'm trying to make. The variable pace of the GC is okay for Go memory, because it can adjust that pace if necessary to keep up with garbage production. The GC can't make pace adjustments based on the consumption of any non-Go-memory resources, which means we can only count on a maximum of 2 minutes between GC runs.

I could certainly see situations where there's no way the GC could make a smart enough decision to fit an application's needs, however. For example, if your program writes to a file that another program then uses, you would want to make sure that the file is closed before that other program is spun up. Even a 1 second GC delay might not work here.

On Sat, Feb 15, 2020 at 10:52 AM Jake Montgomery <jake6...@gmail.com> wrote:

On Friday, February 14, 2020 at 2:10:01 PM UTC-5, Tyler Compton wrote:

The conventional wisdom I see in the Go community is to avoid using finalizers to manage file descriptors, C memory, or any other non-Go memory resource. The generally accepted rationale (at least to my understanding) is that the garbage collector cannot be expected to run the finalizer promptly, and it may never be run at all.

 

This is where I start speculating. I assume this is because the garbage collector has no understanding of C memory, file descriptors, or any other kind of resource. If we're running out of memory due to a malloc in C, there's no way for the garbage collector to know which Go objects it can finalize in order to get that memory back.

I don't think your analysis is correct. IIRC, the spec makes no guarantees about finalizers ever actually being run. But in practice they will all be found and run after the first garbage collection after the object becomes unreachable. (Assuming the app continues to run.) So it's not a matter of  the go runtime not knowing "which Go objects it can finalize in order to get that [a resource] back", its simply a matter of the variable pace of GC. In theory GC can happen as infrequently as every 2 minutes. So if you are ok with you non-Go resource lingering for that long, then use finalizers. In most cases that is not sufficient though.

One other, minor, consideration, is also that setting a finalizer will cause the object to escape to the heap.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/9d2fd31b-f283-4dec-bb38-8cc8cc844249%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu1OF_tBMKXgJKCFU9U_SNvdiKTvg1c%2B9-4KFL7e5jo5bA%40mail.gmail.com.

-- 

You received this message because you are subscribed to the Google Groups "golang-nuts" group.

To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/1347019225.1980.1582049246729%40wamui-fuzz.atl.sa.earthlink.net.