Messages in this thread | | | Subject | Re: FD_CLFORK or equivalent? | Date | Thu, 06 May 1999 07:01:10 +0100 | From | Piete Brooks <> |
| |
> Would this not be more accurate:
Well, "more" accurate, yes, but not correct ..
> struct rlimit *rlim; > if (getrlimit(RLIMIT_NOFILE, rlim)) { /* error */ } > fd = rlim->rlim_cur; > while (fd >=0 ) (void)close(fd--);
As you mention below, the limit can be reduced after a file has been opened, meaning that fd's could be missed.
> Hmmm. Should calling setrlimit(RLIMIT_NOFILE, (struct rlimit *)NULL) > close all open files? It of course doesn't, but should it?
As I understand it, only the kernel actually knowns the upper bound, and without using a HACK such as listing /proc/self/fd/, it would be necessary for the kernel to do the closing -- but I suspect that such a change is likely to breaks certain programmes ...
Hmmm -- reading the man page in pedantic mode allows a different interpretation ....
It suggests to me that by using dup2, it should be possible to get a very high valued fd (much greater than the value of RLIMIT_NOFILE, and that setting RLIMIT_NOFILE to zero *should* close all files :-)) It says: RLIMIT_NOFILE /* max number of open files */ i.e. not (take off one as thge first fd is numbered zero) "the highest value of fd that can be opened" [ which is how I have always interpreted it ] but the *MAX NUMBER* of files (no mention of the fd values) that *CAN BE* open (rather than that open / dup / dup2 can return) -- snigger !
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |