On Wed, Jul 17, 2002 at 02:03:02AM +0100, Alan Cox wrote:
> On Wed, 2002-07-17 at 00:22, Zack Weinberg wrote:
>
> > There's also an ugly semantic bind if you make close detect errors.
> > If close returns an error other than EBADF, has that file descriptor
> > been closed? The standards do not specify. If it has not been
> > closed, you have a descriptor leak. But if it has been closed, it is
> > too late to recover from the error. [As far as I know, Unix
> > implementations generally do close the descriptor.]
>
> If it bothers you close it again 8)
Consider:
Two threads share the file descriptor table.
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.
Is step 3 necessary? Is it dangerous? The question is, is close
guaranteed to work, or isn't it?
Case 1: Close is guaranteed to close the file.
Thread 2 may have just re-used the file descriptor. Thus, Thread 1
closes a different file in step 3. Thread 2 is now using a bad file
descriptor, and becomes very angry because the kernel just said all was
right with the world, and then claims there was a mistake. Thread 2
leaves in a huff.
Case 2: Close is guaranteed to leave the file open on error.
Thread 2 can't have just re-used the descriptor, so the world is ok in
that sense. However, Thread 1 *must* perform step 3, or it leaks a
descriptor, the tables fill, and the world becomes a frozen wasteland.
Case 3: Close may or may not leave it open due to random chance or
filesystem peculiarities.
Thread 1 may be required to close it twice, or it may be required not to
close it twice. It doesn't know! Night is falling! The world is in
flames! Aaaaaaugh!
I believe this demonstrates the need for a standard, one way, or the
other. :-)
-J
-
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:21 EST