lkml.org 
[lkml]   [1999]   [May]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: FD_CLFORK or equivalent?
Date
From
> 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/

\
 
 \ /
  Last update: 2005-03-22 13:51    [W:0.079 / U:0.164 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site