• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Reading too many Files into Array returns Nil
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Reading too many Files into Array returns Nil


  • Subject: Re: Reading too many Files into Array returns Nil
  • From: John Stiles <email@hidden>
  • Date: Tue, 13 Sep 2005 08:11:23 -0700

Alexander Repty wrote:

Hello,

John Stiles wrote:

- use setrlimit to raise the limit to the maximum open file limit (there appears to be no downside to this, so I don't know why it isn't the default)
In every non-trivial program I've worked on for OS X, I've always needed the setrlimit code eventually. There's always /something/ that ends up blowing the limit.


most Unix systems employ a way to limit open files per process or in total, and while Mac OS X does not have a total limit on open files per default,

zoidberg:~ arepty$ ulimit
unlimited

it does have standard limits on the various options per process, such as the number of files or filesize. The appropriate manual page is at:

http://developer.apple.com/documentation/Darwin/Reference/ManPages/ man2/setrlimit.2.html

These limit are, as the manpage says, a way to "control maximum system resource consumption" so that for example a runaway user process may not hog an infinite amount of system resources. So, your best bet is to free unused file handles, if that for some reason does not work out for you, get the current limit (getrlimit) and set a higher limit (setrlimit). Just setting the maximum number might cause the system the app is run on to become unusable in case of, for example, a huge loop or bad options supplied by the user. In that case, the process would have to be killed to make the system usable again.

This is a very Unixy way of looking at the world. While not incorrect, it doesn't really consider the world in "personal computer" terms. It's like the rules are written for daemons running on multi-user servers, not user tasks running on a home computer.

If one of our apps has a bug which causes it to get stuck in an infinite loop opening files or something like that, the user will force-quit it. (Or it will crash in some other way, like running out of heap space.) Arbitrarily disallowing opens after 500-ish files are open is just bizarre. Setrlimit seems to be a holdover from the days when every UNIX box needed to support 100 simultanous telnet logins, so the admin adds a simple hack to prevent user X from starving out other users from getting to the precious hard disk. Nowadays this is not a problem that OS X needs to solve; 500 files is /nothing/ in the world of bundled applications. Not only that, but we don't even have a Terminal Services equivalent for multi-user support yet, for crying out loud :)

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


References: 
 >Reading too many Files into Array returns Nil (From: Mike Oldham <email@hidden>)
 >Re: Reading too many Files into Array returns Nil (From: John Stiles <email@hidden>)
 >Re: Reading too many Files into Array returns Nil (From: Alexander Repty <email@hidden>)

  • Prev by Date: OT: porting PC to Mac - possible market?
  • Next by Date: Launching another process, and knowing when it's loaded?
  • Previous by thread: Re: Reading too many Files into Array returns Nil
  • Next by thread: validateForDelete result ignored
  • Index(es):
    • Date
    • Thread