On May 7, 2009, at 6:00 PM, Marcel Weiher wrote:
And yes, the code that I use explicitly runs the runloop, and it
is the code that runs the runloop that both allocates the
NSURLConnection and then cleans up after it checks the flag.
Perfectly safe, perfectly synchronous.
That's not what I was talking about. I was talking about the
possibility that the 'owned' caller manually runs the run loop
right after it calls the delegate callback, so any performSelector:
called by the delegate will be performed after the delegate
callback returns but within the scope of the caller. How do you
protect against that?
*I* don't. It is you who wants these sorts of guarantees and
protections. I code in ways that don't assume these sorts of
protections.
How? That's what I'm asking about. If you have a good solution to the
problem of when it's safe for the owner and/or delegate to dispose of
an object that performs async operations with delegate callbacks, I'm
certainly willing to consider it. Otherwise, there seems to be no real
alternative to autoreleasing in a callback.
_______________________________________________
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
