alt Hacker News> In fact it’s quite common to “commit” on close, at least from what I’ve seen.
close(2) does not "commit". You have to call v.Sync() (i.e. fsync(2)) for that.
From man 2 close:
A successful close does not guarantee that the data has been successfully saved to disk, as the kernel uses the buffer cache to defer writes. Typi‐
cally, filesystems do not flush buffers when a file is closed. If you need to be sure that the data is physically stored on the underlying disk, use
fsync(2). (It will depend on the disk hardware at this point.)
I think we’re talking past each other.
I was not talking about file descriptors; rather I was talking about the fact that it’s common for Go libraries to do interesting and useful things when you call the `Close()` method on a type. `Close()` is idiomatic go for resource cleanup.
You might wait until close to populate a length and or checksum field in a message header. Or close could submit a buffer of log events to a remote aggregation endpoint.
I’m not saying I agree with APIs that are designed that way, but it’s common enough that you should assume the error return value is significant unless you know otherwise (for Go)