Re: Async NSURLConnection and blocks (was: Running NSURLConnection from within an NSOperation?)
Re: Async NSURLConnection and blocks (was: Running NSURLConnection from within an NSOperation?)
- Subject: Re: Async NSURLConnection and blocks (was: Running NSURLConnection from within an NSOperation?)
- From: Kevin Wojniak <email@hidden>
- Date: Mon, 21 Jun 2010 10:48:37 -0700
NSURLConnection already does its work asynchronously, there is no need to run it on a separate thread. However if you still want to, you should use [NSRunLoop currentRunLoop], which returns the run loop associated with that thread.
In your code you are not creating your objects properly. You should use the form [[Class alloc] init] then operate on that object:
> NSURLConnection *connection = [[NSURLConnection alloc] initWithRequest:urlRequest delegate:handler startImmediately:NO];
Also I don't believe you need to create the autorelease pool. I think GCD does it for you.
Lastly, you should run the thread's run loop until your delegate method gets called indicating the NSURLConnection is done.
On Jun 20, 2010, at 1:42 PM, John Heitmann wrote:
>
> On Feb 9, 2010, at 3:01 PM, Keith Duncan wrote:
>
>> ...you should create a 'concurrent' NSOperation as described in the documentation, and schedule your NSURLConnection on +[NSRunLoop mainRunLoop]. This will allow your NSOperation -start method to exit immediately and the thread to return to the pool.
>
> I had a working async NSURLConnection scheme where I initialized the connection in a new thread and pumped its run loop manually on that thread until I saw the delegate set a completion flag. I thought I'd convert it to blocks since it cleans up some ugly code there. I'm 95% of the way there and things look good, but there are some lingering problems in my code that I don't understand. The above tip helped with one of my problems: the automatic block thread didn't pump the NSURLConnection run loop, so I scheduled the connection in the main run loop like Keith suggested and things worked. My first question is: doesn't this block the main loop with io? I have another version which uses a block to manually pump, but then this ties up an automatic block thread, which are supposed to be short-lived. Is it really a good practice to drive the NSURLConnection from the main loop?
>
> My second question is: How do I memory manage the autorelease pool that the delegate uses? Here's a rough idea of what I have now:
>
> dispatch_queue_t queue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
> dispatch_async(queue, ^{
> __block NSAutoreleasePool *autoReleasePool = [[NSAutoreleasePool alloc] init];
> NSURLConnection *connection = [NSURLConnection alloc];
> ResponseHandler *handler = [ResponseHandler alloc];
>
> [handler initWithDelegate:delegate
> completionBlock:^{dispatch_async(queue, ^{
> [connection release];
> [handler release];
> [autoReleasePool release];
> [delegate release];
> });}];
>
> [connection initWithRequest:urlRequest delegate:handler startImmediately:NO];
> [connection scheduleInRunLoop:[NSRunLoop mainRunLoop] forMode:NSDefaultRunLoopMode];
> [connection start];
> });
>
> ResponseHandler is pretty simple. It processes the data and calls the completionBlock when done. With that code I get "attempt to pop an unknown autorelease pool". When I drop the release altogether the error goes away, but that seems like a leak.
>
> John_______________________________________________
>
> Cocoa-dev mailing list (email@hidden)
>
> 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:
>
> This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden