Post by Stevie O Post by Elladan
1. Thread 1 performs close() on a file descriptor. close fails.
2. Thread 2 performs open().
* 3. Thread 1 performs close() again, just to make sure.
open() may return any file descriptor not currently in use.
I'm confused here... the only way close() can fail is if the file
descriptor is invalid (EBADF); wouldn't it be rather stupid to close()
a known-to-be-bad descriptor?
Well, obviously, if that's the case. However, the man page for close(2)
doesn't agree (see below). close() is allowed to return EBADF, EINTR,
The question is, does the OS standard guarantee that the fd is closed,
even if close() returns EINTR or EIO? Just going by the normal usage of
EINTR, one might think otherwise. It doesn't appear to be documented
one way or another.
Alan said you could just issue close again to make sure - the example
shows that this is not the case. A second close is either required or
forbidden in that example - and the behavior has to be well defined or
you won't know which to do.
close - close a file descriptor
int close(int fd);
close closes a file descriptor, so that it no longer refers
to any file and may be reused. Any locks held on the file it
was associated with, and owned by the process, are removed
(regardless of the file descriptor that was used to obtain the
If fd is the last copy of a particular file descriptor the
resources associated with it are freed; if the descriptor was the
last reference to a file which has been removed using unlink(2)
the file is deleted.
close returns zero on success, or -1 if an error occurred.
EBADF fd isn't a valid open file descriptor.
EINTR The close() call was interrupted by a signal.
EIO An I/O error occurred.
SVr4, SVID, POSIX, X/OPEN, BSD 4.3. SVr4 documents an
additional ENOLINK error condition.
Not checking the return value of close is a common but
nevertheless serious programming error. File system
implementations which use techniques as `write-behind' to
increase performance may lead to write(2) succeeding, although
the data has not been written yet. The error status may be
reported at a later write operation, but it is guaranteed to be
reported on closing the file. Not checking the return value when
closing the file may lead to silent loss of data. This can
especially be observed with NFS and disk quotas.
A successful close does not guarantee that the data has
been successfully saved to disk, as the kernel defers
writes. It is not common for a filesystem to flush the
buffers when the stream is closed. If you need to be sure
that the data is physically stored use fsync(2) or
sync(2), they will get you closer to that goal (it will
depend on the disk hardware at this point).
open(2), fcntl(2), shutdown(2), unlink(2), fclose(3)