2
votes

Is anyone else having this problem with ASIHTTPRequest? It seems that when I perform an async request from within a background thread with delegate set to the instance I can run into trouble as the delegate can be freed before the request (which is put into an NSOperationQueue) returns a callback.

It seems that ASIHTTPRequest doesn't retain it's delegate - on the other hand Apple's NSURLConnection does retain the delegate ("NSURLConnection retains its delegate when it is initialized. It releases the delegate when the connection finishes loading, fails, or is canceled.").

Should I make sure to perform synchronous ASIHTTPRequests in background threads to make this work (instead of async requests)? Or maybe I should dump ASIHTTPRequest? Or am I just crazy?

2
I'm not sure why this has got marked as "community wiki"?JosephH

2 Answers

7
votes

Assuming you're using a very recent version of ASIHTTPRequest, the correct way to work with it (and avoid crashes) is that:

The delegate should retain the request (and the request should not retain the delegate)

The delegate should do the following when the delegate is destroyed (or when you want to cancel the request):

[request setDelegate:nil];    
[request cancel];
[request release];

You shouldn't get any crashes this way. (I rewrote the delegate handling in ASIHTTPRequest a few months ago exactly to avoid some of these issues, and I checked with the folks from Apple that this was a correct way to handle things before doing so. My changes are all in the official ASIHTTPRequest repository on github, though there hasn't been an official release since - ie. these changes aren't in the v1.7 release, so with v1.7 or earlier you could still see crashes when following the above advice.)

0
votes

I don't know if ASIHTTPRequests doesn't retain the object, but did you try to retain it when performing and the releasing it at the end ?

I never had a problem yet with this very good wrapper ^^