> On 30 Jul 2015, at 01:55, Rick Mann <rm...@latencyzero.com> wrote: > > I'm starting hundreds of download tasks on a single NSURLSession. The session > nicely limits the number of concurrent downloads, and everything seems to > behave, until I some time has elapsed equal to the default value of > timeoutIntervalForRequest, 60 seconds (I don't currently adjust this). > > Others have experienced this, as evidenced by this post > (http://stackoverflow.com/questions/20888841/set-number-of-concurrent-downloads-with-nsurlsessiondownloadtask). > The problem is that the timer for the request is started when the task is > resumed, and not when its request is actually first issued. This means that > if you have more tasks than the HTTPMaximumConnectionsPerHost, and those > tasks take longer than timeoutIntervalForRequest, the next task will time > out, even though it hasn't yet begun. > > I think this is a bug, and I'm filing it as such, but I wanted to get other > opinions. It seems the only workaround is to make the > timeoutIntervalForRequest very long, too, which is gross, as a single request > may legitimately time out in a short amount of time, but the large set of > tasks could take much longer to run through.
When NSURLSession was first announced, I believe I enquired about this and was told the timeout timer isn’t supposed to kick off until the task actually does some work. That says to me the behaviour you’re seeing is a bug, and worth complaining about. The trouble is it’s shipping now, so we’re probably just stuck with it, sadly. One possibility that comes to mind is the behaviour between regular and background sessions might be different — have you experimented with that at all? Mike. _______________________________________________ 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