Which objects are finalized in Go by default and what are some of the pitfalls of it?

Question

The function runtime.SetFinalizer(x, f interface{}) sets the finalizer associated with x to f.

What kind of objects are finalized by default?

What are some of the unintended pitfalls caused by having those objects finalized by default?

Jacquetta

Note the many caveats listed in the runtime.SetFinalizer documentation. You should never depend on or expect a finalizer to ever get run. Instead, always make sure to call the appropriate cleanup function(s) (e.g. defer file.Close() right after checking the errors of os.Open). – Champaigne

Answer 1

The following objects are finalized by default:

• os.File: The file is automatically closed when the object is garbage collected.

• os.Process: Finalization will release any resources associated with the process. On Unix, this is a no-operation. On Windows, it closes the handle associated with the process.

• On Windows, it appears that package net can automatically close a network connection.

The Go standard library is not setting a finalizer on object kinds other than the ones mentioned above.

There seems to be only one potential issue that may cause problems in actual programs: When an os.File is finalized, it will make a call to the OS to close the file descriptor. In case the os.File has been created by calling function os.NewFile(fd int, name string) *File and the file descriptor is also used by another (different) os.File, then garbage collecting either one of the file objects will render the other file object unusable. For example:

package main

import (
    "fmt"
    "os"
    "runtime"
)

func open() {
    os.NewFile(1, "stdout")
}

func main() {
    open()

    // Force finalization of unreachable objects
    _ = make([]byte, 1e7)
    runtime.GC()

    _, err := fmt.Println("some text") // Print something via os.Stdout
    if err != nil {
        fmt.Fprintln(os.Stderr, "could not print the text")
    }
}

prints:

could not print the text

Jacquetta

The above code pasted unchanged to both golang.org's and weekly.golang.org's playgrounds print in both cases: some text – Nomism

@jnml: os.File.Close() function does not work at all in the playgrounds for some reason. See play.golang.org/p/qNj8LRXQny – Jacquetta

As of Go 1.4.2 (and probably earlier) this example runs fine. It's unclear if the finalizer isn't getting called or if it is called and now "does the right thing". – Champaigne

Answer 2

Just jump into the os.NewFile's source code:

// NewFile returns a new File with the given file descriptor and name.
func NewFile(fd uintptr, name string) *File {
    fdi := int(fd)
    if fdi < 0 {
        return nil
    }
    f := &File{&file{fd: fdi, name: name}}
    runtime.SetFinalizer(f.file, (*file).close)  // <<<<<<<<<<<<<<
    return f
}

• When go runs GC, it will run Finalizers bind on that object.
• When you open a new file, the go library will bind a Finalizer on that returned object for you.
• When you are not sure what the GC will do to that object, jump to source code and check whether the library has set some finalizers on that object.

Tirpitz

Answer 3

"What kind of objects are finalized by default?"
Nothing in Go is IMO finalized by default.

"What are some of the unintended pitfalls caused by having those objects finalized by default?"
As per above: none.

Nomism

Are you able create a Go program that opens a file and the returned *os.File has finalization turned off (without modifying the source code of Go's standard packages)? If you aren't able to do that, it means that all instances of os.File are finalized by default. – Jacquetta

I'm talking about Go, not about any library. – Nomism

I'm talking about Go as a whole (including the standard packages). – Jacquetta

@Atom: Still the same. *os.File is finalized by explicitly setting a finalizer in the package code. Nothing in Go, neither in any library is "finalized by default". – Nomism