Sponsored Content
Full Discussion: Which is more expensive ?
Top Forums Programming Which is more expensive ? Post 302131754 by porter on Monday 13th of August 2007 02:21:18 PM
Old 08-13-2007
Quote:
Originally Posted by vino
I was told that you generally need to close only 64 fds instead of the RLIMIT.rlim_cur after forking. Any thoughts ?
You need to close the file descriptors you need to close. Smilie

The number 64 comes from some editions of UNIX's hard coded limit.

There are alternatives...

1. If the reason is the program is going to call 'exec' then the code that opens the file descriptors could set the close-on-exec bit.

2. Modular threaded code could use pthead_atfork to set up a call back to close a file descriptor if required.
 

2 More Discussions You Might Find Interesting

1. Programming

calling pthread_self (on ubuntu), expensive?

Hi all, Is anyone aware of what operations are involved when a call to pthread_self() is made, obtaining the unique thread ID on a Ubuntu system (or even any Linux flavour)? Specifically, to retrieve the thread id, is there any locking required or atomic operations? I'm building an... (11 Replies)
Discussion started by: gorga
11 Replies

2. What is on Your Mind?

Very Expensive Running Shoes

You really should not need one third of the entire US budget to buy a pair of running shoes... even if they are name brand. What have these guys been smoking? It reminds me of the old joke... Customer: At those prices you aren't going to sell many shoes. Salesman: Ah, but all we need to do is... (4 Replies)
Discussion started by: Perderabo
4 Replies
CLOSE(2)						      BSD System Calls Manual							  CLOSE(2)

NAME
close -- delete a descriptor LIBRARY
Standard C Library (libc, -lc) SYNOPSIS
#include <unistd.h> int close(int fd); DESCRIPTION
The close() system call deletes a descriptor 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; on the last close of a file holding an advisory lock the lock is released (see further 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 processes, the close() system 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 is then to be run using execve(2), the process would normally inherit these descriptors. Most of the descriptors can be rearranged with dup2(2) or deleted with close() before the execve(2) is attempted, but if some of these descriptors will still be needed if the execve fails, it is necessary to arrange for them to be closed if the execve succeeds. For this reason, the call ``fcntl(d, F_SETFD, FD_CLOEXEC)'' is provided, which arranges that a descriptor will be closed after a successful execve; the call ``fcntl(d, F_SETFD, 0)'' restores the default, which is to not close the descriptor. RETURN VALUES
The close() function returns the value 0 if successful; otherwise the value -1 is returned and the global variable errno is set to indicate the error. ERRORS
The close() system call will fail if: [EBADF] The fd argument is not an active descriptor. [EINTR] An interrupt was received. [ENOSPC] The underlying object did not fit, cached data was lost. [ECONNRESET] The underlying object was a stream socket that was shut down by the peer before all pending data was delivered. In case of any error except EBADF, the supplied file descriptor is deallocated and therefore is no longer valid. SEE ALSO
accept(2), closefrom(2), execve(2), fcntl(2), flock(2), open(2), pipe(2), socket(2), socketpair(2) STANDARDS
The close() system call is expected to conform to ISO/IEC 9945-1:1990 (``POSIX.1''). HISTORY
The close() function appeared in Version 7 AT&T UNIX. BSD
September 11, 2013 BSD
All times are GMT -4. The time now is 07:14 PM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy