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 > <https://groups.google.com/d/msgid/golang-nuts/9d2fd31b-f283-4dec-bb38-8cc8cc844249%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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.
