4 ms·
Sure. But if you think that a file will be closed by the runtime "when there are no more references to it" then you're prone to assume that that the file must b
by ithkuil 3y ago
Sure. But if you think that a file will be closed by the runtime "when there are no more references to it" then you're prone to assume that that the file must be closed when you later reopen the file or pass that filename to some other process . And most of the times the file will be indeed closed, until the GC just happens to run the finalized a little bit later than usual.
It's very hard to debug such bugs.
Imo it's much easier to make the leak more prominent so that people are incentivised to properly close the files
- cratermoon 3y agoIt's possible to use Go's pprof to find leaks. Also, if it's important enough then runtime.SetFinalizer(fd, any) will allow the programmer to do something appropriate.
- yawaramin 3y agoSo will 'defer', and that is much more idiomatic and well-understood in the Go community.
- cratermoon 3y agoGranted, but that only works for a subset of all cases. Remember that FDs can also refer to sockets and other things that aren't "files". A careful programmer will ensure that all FDs get cleaned up, but even careful programmers can fall victim to corner cases.
- yawaramin 3y agoI don't see why 'defer' wouldn't work for FDs or any other resource. There's nothing about 'defer' that says it will work only with 'files'. In fact I've been using it for general-purpose resource management for a while now.