On Fri, May 8, 2009 at 1:43 AM, Marcel Weiher <marcel.wei...@gmail.com> wrote: > > On May 7, 2009, at 21:12 , Michael Ash wrote: > >> On Thu, May 7, 2009 at 11:53 PM, Marcel Weiher <marcel.wei...@gmail.com> >> wrote: >>> >>> On May 7, 2009, at 17:29 , Jeff Johnson wrote: >>> >>>> On May 7, 2009, at 6:00 PM, Marcel Weiher wrote: >>>> >>>>>> 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? >>> >>> Begin forwarded message: >>> >>>> From: Marcel Weiher <marcel.wei...@gmail.com> >>>> Date: May 7, 2009 10:05:29 PDT >>>> >>>> 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. >> >> And what about the *a*synchronous case? > > That *was* the asynchronous case, which I then proceeded to make > synchronous.
Which means it's synchronous. How would you handle an asynchronous connection? Mike _______________________________________________ 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
