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.
Marcel
_______________________________________________
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
