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 (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:
> http://lists.apple.com/mailman/options/cocoa-dev/kainjow%40kainjow.com
>
> This email sent to kain...@kainjow.com
_______________________________________________
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
