5 ms·
I dislike the multiple close pattern - I was bitten by this behavior years ago, when the second close() ended up closing another file which had been opened betw
by Agingcoder 2y ago
I dislike the multiple close pattern - I was bitten by this behavior years ago, when the second close() ended up closing another file which had been opened between the first and second close ( I think they were actually sockets ). It was a bona fide bug on my side , but it made for unpleasant memories, and a general distrust of such idioms on my side unless there's a language wide guarantee somewhere in the picture.
- jsndnnd 2y agoI don't understand how that could happen, since the original file handle would have been invalidated. Which operating system did you experience this under and was it the operating system, your Libc or what else in the stack which caused this?
- dwattttt 2y agoThe scenario is that after the original file handle is closed, a new open occurs and the file is assigned the same handle value. Then code acting on the stale handle of the first file closes it, and accidentally closes the new file instead.
- dlock17 2y agoIn the stdlib Go code for file.Close, it doesn't actually do the syscall after the first call to Close, so there's your language guarantee. That is a scary sounding error though.
- Agingcoder 2y agoOlder versions of go (1.0 for example ) were much less safe. I had a look at the code, and it closes the file directly, and marks it as unusable. However, if you do concurrent operations, you can race and close twice the underlying fd - which I think was my bug ( I shouldn’t have been closing things twice anyway !)