|CLOSE(2)||System Calls Manual||CLOSE(2)|
close() call deletes a descriptor d from the per-process object reference table. If this is the last reference to the underlying object, the object will be deactivated. For example, on the last close of a file, the current seek pointer associated with the file is lost; on the last close of a socket(2), associated naming information and queued data are discarded; and on the last close of a file holding an advisory lock, the lock is released (see flock(2)). However, the semantics of System V and IEEE Std 1003.1-1988 (“POSIX.1”) dictate that all fcntl(2) advisory record locks associated with a file for a given process are removed when any file descriptor for that file is closed by that process.
When a process exits, all associated file descriptors are freed,
but since there is a limit on active descriptors per process, the
close() function call is useful when a large
quantity of file descriptors are being handled.
When a process forks (see
fork(2)), all descriptors for
the new child process reference the same objects as they did in the parent
before the fork. If a new process image is to then be run using
execve(2), the process would
normally inherit these descriptors. Most of the descriptors can be
rearranged with dup2(2) or
close() before the
execve(2) is attempted, but
since some of these descriptors may still be needed should the
execve(2) fail, it is
necessary to arrange for them to be closed when the
execve(2) succeeds. For this
reason, the call
F_SETFD, FD_CLOEXEC) is
provided, which arranges that a descriptor will be closed after a successful
execve(2); the call
F_SETFD, 0) restores the
default, which is to not close the descriptor.
close() will fail if:
close() conforms to IEEE Std 1003.1-2008 (“POSIX.1”).
close() system call first appeared in Version 1 AT&T UNIX.
|December 10, 2014||OpenBSD-5.9|