Messages in this thread | | | From | Florian Weimer <> | Subject | Re: 2.6.28, rlimits, performance and debian etch | Date | Sun, 25 Jan 2009 11:59:06 +0100 |
| |
* David Daney:
> One problem is that for values of RLIMIT_NOFILE less than something > like 4096, it is much faster to call sys_close() on all possible > values than iterate through a handful of open files from /proc/self/fd > using opendir(3)/readdir(3).
Really? Yuck.
> The real solution is to convert your user space programs to use the > new syscalls that allow for race-free setting of close-on-exec. > Then you no longer need to mess around with iterating over these > things.
These system calls are too recent to use in the next two Debian releases. In addition, we can't really be sure that all libraries use the new calls.
I find the design of the CLOEXEC business somewhat revulsive, by the way. It reminds me of those DoSomethingEx APIs in another platform. The *_at system calls are a similar wart. Even with this stuff, I still can't safely open a file with a different effective user ID in a multithreaded application, or create a AF_UNIX socket with specific file system permissions. Some thread-specific context with what have been traditionally considered per-process attributes might have been better. 8-(
| |