Hacker News Reader

Comment by Agingcoder | Hacker News Reader

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.

View on HN

I 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?

The 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.

In 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.

Older 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 !)

Reply on news.ycombinator.com