On Sat, 10 Sep 2005 12:00:01 -0700 (PDT)
Linus Torvalds <[email protected]> wrote:
> Re-doing the close() is the wrong thing to do, since in a threaded
> environment, something else might have opened another file, gotten
> the same file descriptor, and you now close _another_ file.
So glibc doc is wrong here:
http://www.gnu.org/software/libc/manual/html_node/Opening-and-Closing-Files.html#index-close-1197
-----------------------------------------------------------------------
The normal return value from close is 0; a value of -1 is returned in
case of failure. The following errno error conditions are defined for
this function:
...
EINTR
The close call was interrupted by a signal. See Interrupted
Primitives. Here is an example of how to handle EINTR properly:
TEMP_FAILURE_RETRY (close (desc));
-----------------------------------------------------------------------
And: /usr/include/unistd.h
# define TEMP_FAILURE_RETRY(expression) \
(__extension__ \
({ long int __result; \
do __result = (long int) (expression); \
while (__result == -1L && errno == EINTR); \
__result; }))
#endif
SUSV3:
-------------------------------------------------------------
If close() is interrupted by a signal that is to be caught, it shall
return -1 with errno set to [EINTR] and the state of fildes is
unspecified
-------------------------------------------------------------
Unspecified! ;-)
--
Paolo Ornati
Linux 2.6.13.1 on x86_64
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
|
|