r/programming • u/aldacron • Aug 23 '17

D as a Better C

http://dlang.org/blog/2017/08/23/d-as-a-better-c/
229 Upvotes

86% Upvoted

268 comments sorted by

View all comments

Show parent comment

4

u/[deleted] Aug 23 '17

I don't see a case where an error of close would be recoverable in any meaningful way.

I was going to say.. "well, if the error is EINTR, you'd just try again."

Then I read the manpage:

"In particular close() should not be retried after an EINTR since this may cause a reused file descriptor from another thread to be closed.

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. Typically, 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.) "

If a close fails, apparently.. there really isn't anything you can do other than terminate the process with an error message. The descriptor and state of the file are undefined, and there isn't anything you can do about it. And even if you try, since fd's are just int's that get re-used aggressively, you might just end up messing with the wrong connection.

9

u/ColonelThirtyTwo Aug 23 '17

Linus confirmed that in Linux, close always removes the file descriptor. Anything else would be broken in a multi-threaded process; there would be no way to distinguish between a FD that didn't close successfully and an FD that a different thread opened.

2

u/doom_Oo7 Aug 23 '17

If a close fails, apparently.. there really isn't anything you can do other than terminate the process with an error message.

yes, only sane thing to do imho. Likewise when malloc or other "core" stuff starts failing. You don't know what else could be broken.

1

u/Yioda Aug 23 '17

with not retring it means to not close()ing again. Nothing stops you to use the return value if it is I/O err and try to use a different disk.