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.
