Re: shm_open and EMFILE
Re: shm_open and EMFILE
- Subject: Re: shm_open and EMFILE
- From: Terry Lambert <email@hidden>
- Date: Fri, 15 Feb 2008 22:17:21 -0800
There are some descriptors used up for normal housekeeping. Also
realize that for ach one you have open, that's a file, socket, pipe,
etc. that you are not going to be able to open.
stdin, stdout, stderr = 3
10237 + 3 = 10240
-- Terry
On Feb 14, 2008, at 11:46 PM, David McGavran wrote:
Ok I guess this is good news then :)
Thanks! I love it when I am wrong :)
I did a much more simple test and was able to hit 10237 which is
much closer to the max of 10240 as I hoped. There must be something
else wrong, I will have to dig deeper.
Cheers
Dave
On Feb 15, 2008, at 2:05 AM, Terry Lambert wrote:
On Feb 14, 2008, at 11:43 AM, David McGavran wrote:
I would guess this has been asked and answered so any pointers are
fine. I tried to check the digest but didn't find the answer.
I am trying to setup a lot of mem mapped files. But at or around
240 I get EMFILE which man page says means I have too many open.
If I am not mistaken on 10.5 at least we are allowed 12000 or so
open files? Why can I only open 240 or so memory mapped files?
You are mistaken.
The limit on the number of files for a process is by default 256,
as a soft constraint, and the value of maxfiles, as a hard
constraint. The value of maxfiles represents the maximum number of
files permitted an individual process.
In addition, there is a hard constraint based on whatever your
parent process decides to constrain you to; the default value of
this is "unlimited" (by which it means "whatever the current sysctl-
based hard limits are"). Once lowered the value of the hard limit
cannot be reaised except by a process with root privilege.
The value of maxfiles is reported by the sysctlbyname() value for
"kern.maxfilesperproc"; this in turn is constrained by the the
sysctlbyname() value for "kern.maxfiles", which is a compile time
system limit.
Note that the use of actual file descriptors to implement POSIX
shared memory is an implementation detail, so all of the above is
potentially subject to change in its relevency if that
implementation detail ever changes.
What can I do to open more?
man 2 setrlimit
Also note that other administrative constraints other than number
of available file descriptors (such as available kernel memory)
will potentially also cause your attempt to ail (e.g. ENOMEM,
ENOSPC, SPERM, EACCES, etc.).
-- Terry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden