On Sunday, September 30, 2018 at 4:56:20 PM UTC-5, Kane York wrote: > > In Go, it's usually better to use source code analysis to look for > forgotten Close calls, like the existing tooling for os.File (which does > have a finalizer, but doesn't need to).
*os.File has a finalizer for the same reason that this code needs one - it holds onto an external resource with some kind of ID that needs to be closed manually through an API call. Even though runtime.SetFinalizer doesn't guarantee the finalizer will be called, the only reason it wouldn't be called is if the memory wasn't garbage-collected before the process exits (or the computer is unplugged, etc). In a long-running process, that isn't an issue for finalizers that just do cleanup. -- 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. For more options, visit https://groups.google.com/d/optout.
