From mboxrd@z Thu Jan 1 00:00:00 1970 From: Zack Weinberg To: "H . J . Lu" Cc: gcc@gcc.gnu.org Subject: Re: Problems with the cpp change after 2000-06-18 Date: Mon, 03 Jul 2000 16:24:00 -0000 Message-id: <20000703162429.K274@wolery.cumb.org> References: <20000703100919.A1221@lucon.org> <20000703102201.F274@wolery.cumb.org> <20000703104138.A1321@lucon.org> <20000703105438.H274@wolery.cumb.org> <20000703153013.A2200@lucon.org> X-SW-Source: 2000-07/msg00037.html On Mon, Jul 03, 2000 at 03:30:13PM -0700, H . J . Lu wrote: > On Mon, Jul 03, 2000 at 10:54:38AM -0700, Zack Weinberg wrote: > > > > Try using ulimit -n. > > > > > > > > > > I have to build kernel as root. I am not sure "ulimit -n" will help. > > > > Funny, I've never had any trouble building kernels as an unprivileged > > user. > > > > In any case, resource limits apply to uid 0 processes just as they > > would any other process; sure, they can call setrlimit() and raise > > them, but cpp doesn't do that. > > "ulimit -n" seems to work for root. The problem is "ulimit -n" may > not work for me in my shell since other processes have legitimate > reasons to open many files. Which is why this is a test, not the solution - see the other message. > I tried "ulimit -n 16" which failed. I am running ""ulimit -n 32" > now. It will take at least an hour to know for sure. Also I don't > know how portable setrlimit() will be. Is that in libiberty? A > counter in cpp should work ok. Believe me, I have no intention of dinking with resource limits inside cpplib. We may indeed wind up with a counter. Another option is to cache the contents of the file instead of the file descriptor; that would save even more work, and avoid holding files open. Question for the audience in general: Are there any supported platforms where autoconf thinks we can mmap files (HAVE_MMAP_FILE) but the kernel chokes if you close the file descriptor before you destroy the mapping? (I have dim memories of NT acting like this...) And are there any supported platforms, etc. with a small limit on the number of distinct file mappings active at once (entire system or per-process)? zw