On Wed, Jul 17, 2002 at 12:17:40AM -0400, Stevie O wrote:
> At 07:22 PM 7/16/2002 -0700, Elladan wrote:
> > 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,
or EIO.
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.
-J
NAME
close - close a file descriptor
SYNOPSIS
#include <unistd.h>
int close(int fd);
DESCRIPTION
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
lock).
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.
RETURN VALUE
close returns zero on success, or -1 if an error occurred.
ERRORS
EBADF fd isn't a valid open file descriptor.
EINTR The close() call was interrupted by a signal.
EIO An I/O error occurred.
CONFORMING TO
SVr4, SVID, POSIX, X/OPEN, BSD 4.3. SVr4 documents an
additional ENOLINK error condition.
NOTES
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).
SEE ALSO
open(2), fcntl(2), shutdown(2), unlink(2), fclose(3)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Jul 23 2002 - 22:00:22 EST