> On 6 Feb 2015, at 6:48 am, Greg Parker <gpar...@apple.com> wrote: > > You can use getrlimit(RLIMIT_NOFILE, …) to query the limit in your process, > and setrlimit(RLIMIT_NOFILE, …) to attempt to raise it. The default limit may > be as low as 256, depending on OS version and on how the process is launched. > (Note that each two-way network connection uses two file descriptors.) > setrlimit() should be able to raise the file descriptor limit to a few > thousand unless your system administrator is mean.
This is great. Running from XCode I get 7168, archiving and exporting a final build of my app, I get 256... bingo! Only the built version was seeing this crash, another reason I was having a lot of trouble debugging it. With 50 tasks, creating 50 NSURLSession, that accounts for 100 file descriptors. I'm supposing the rest come from other places - in fact each of my tasks potentially creates 2 NSURLSession, though these second ones are highly conditional on what the first ones return, and usually are NOT created, so I doubt that I was immediately creating 200 file handles. I've redesigned part of my app so that a shared NSURLSession is used across all tasks for the first type of session, leaving the individual sessions for the second type, which are architecturally unrelated to the first kind and created by a completely different object, so that should help a lot in the first place. I will also up the filehandle limit to give it a bit more headroom - I would imagine in practice that 50 tasks is a reasonable upper limit that the user would create - I can add some constraints on that in my UI. > > If you hit that limit you should see errors from various network API. File a > bug report if you find some API that causing weird crashes instead of failing > gracefully or halting with an appropriate error message when you run out of > file descriptors. Well I'm seeing EXC_GUARD. Is that considered "graceful"? From the user's perspective it isn't, because it causes summary termination of the app which is almost always reported as "it crashed, wah!, you suck!". Ultimately this should propagate up to the NSURLSession API in some way - e.g. by returning nil instead of an object if it can't create its resources. I think one problem there is that the API is asynchronous - it creates the object which then starts a thread to open the socket - that's what the stack trace implies anyway. That would make it hard to simply not return a valid object. Not sure what the right design would be there - that's one for the networking architects to ponder I guess. Anyway, thanks for everyone's replies - I have gained a lot of insight into things that I didn't have before - I haven't done much network stuff before. --Graham _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
