Re: Canceling and then retrying a bunch of tasks
Re: Canceling and then retrying a bunch of tasks
- Subject: Re: Canceling and then retrying a bunch of tasks
- From: Rick Mann <email@hidden>
- Date: Tue, 08 Dec 2015 14:32:13 -0800
> On Dec 8, 2015, at 01:11 , Quinn The Eskimo! <email@hidden> wrote:
>
>
> On 8 Dec 2015, at 01:58, Rick Mann <email@hidden> wrote:
>
>> Also, I presume this only works if the queue is a serial queue, but the docs say it doesn't have to be such.
>
> You really want your NSURLSession delegate queue to be a serial queue. It's going to be very hard to maintain coherent state otherwise. Moreover, your delegate queue work should be fast, so serialisation isn't a problem. If you need to do real work in this context, that work itself should be farmed off to a separate thread/queue/NSOperation.
Yes, it has always been a serial queue. Rather, it's the default queue created by NSURLSession (which the docs say is serial). I pass nil in this parameter.
Also, I use callback blocks, not delegates.
>
> On 8 Dec 2015, at 03:52, Rick Mann <email@hidden> wrote:
>
>> And, the answer is no. My completion block gets called MANY more times after I invalidate and cancel the session.
>
> I'm confused by this. Are you looking to invalidate the session or not? If you don't mind invalidating the session (-invalidateAndCancel), you should be able to kick off the new work your -URLSession:didBecomeInvalidWithError: delegate callback, which is the last callback you'll get for this session and which will arrive after all your task cancellation callbacks have run.
Here's what I do:
0) Request a list of signed S3 URLs from our endpoint
1) loop through the list of URLs I have to download (300 or so), and create download tasks on a single shared session, with a callback function.
2) Set a breakpoint after a few of these have completed
3) Wait 5 minutes for the signatures to expire
4) Resume running
5) Next callback is 403, call invalidateAndCancel
6) Additional callbacks get called, with more 403 results.
I can't re-start downloads in (5) without some additional state information. If I set a flag that says I've restarted downloads, so that the remaining 403 callbacks don't also restart downloads, then eventually I need to clear that flag, but there's no way to know that the last error has come through.
The only way I can see to do this is to create additional state *per session* to keep track of what's going on, so I can invalidate the session for myself to short-circuit all the additional callbacks, and then create a new session with my additional state to restart the downloads. All because NSURLSession has no mechanism to determine if it's finished with everything. I can't even query NSURLSession to see if it's invalid (which is all the state I really need to short-circuit remaining callbacks).
> Share and Enjoy
> --
> Quinn "The Eskimo!" <http://www.apple.com/developer/>
> Apple Developer Relations, Developer Technical Support, Core OS/Hardware
>
>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Macnetworkprog mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
--
Rick Mann
email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden