> On Nov 23, 2016, at 08:16 , Shawn Erickson <shaw...@gmail.com> wrote: > > We throttle for 3 main reasons. 1) Starting many requests - in our experience > - results in a far higher likelihood of requests randomly timing out. It > seems like the timeout starts ticking relative to creation of the task - > possibly initial resume - and not after some internal throttling takes place. > That makes firing off a large number of requests a little to non > deterministic. We can arbitrarily bump the data timeout to hide this issue > but we don't like that for other reasons.
Yeah, I mentioned this in one of my replies in this thread. It seems the URLSessionConfiguration.timeoutIntervalForRequest is not per-request, in that the timer seems to start as soon as the task is resumed, not when the task request is actually issued over the wire. I can see that interpretation making some sense, but in practice it's not particularly useful, I think. I wrote a bug about this (22064437) over a year ago (July 2015), and it was marked a duplicate of (20976043, a million bugs earlier*), which is still open. *Does anyone know if Radar increments bug IDs by one? They do seem to be monotonically increasing, but it's astonishing, the rate at which bug numbers increase. -- Rick Mann rm...@latencyzero.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Macnetworkprog mailing list (Macnetworkprog@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/macnetworkprog/archive%40mail-archive.com This email sent to arch...@mail-archive.com
