On May 8, 2009, at 6:50 , Michael Ash wrote:
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.
No, the underlying NSURLConnection calls and callbacks are still the
asynchronous and more importantly (to me anyway) incremental ones.
How would you handle an asynchronous connection?
How many times do I have to repeat my answer? I can't help it if you
don't like my solution, but that is *my* solution.
Anyway, this whole thing about NSURLConnection and asynchronous
'callbacks' is nothing but a diversion anyway. The original problem
is one of releasing an object from a synchronous callback in
NSXMLParser, and a whole host of misunderstandings: (1) that
NSXMLParser callbacks are asynchronous, which they are not and (b)
that there are guarantees that an object autoreleased by the callee is
guaranteed to survive a return from the caller, which it is not (c)
that autoreleased objects are guaranteed to exist until the end of the
current event loop, which they are not etc.
As a general note, asynchronous communication has to be handled quite
differently, because there isn't a well-defined relationship between
the message source and the receiver in terms of call hierarchy. For
example, the message-send is done via one of runloop performer
methods, then the sender of the message may not be on the call-stack
at all at the time the message is received. With NSURLConnection, the
situation seems to be a bit different, it appears to be the
NSURLConnection itself that handles some of that scheduling and then
does a synchronous callback to the delegate.
However, because there is actually no reference required, it appears
obvious (from the retain/release rules if nothing else), that
something else must be holding on to the NSURLConnection while it is
doing its asynchronous downloading operation. Certainly that is what
I do with async./threaded operations: retain myself at the start,
release myself at the end, so I can guarantee (modulo over-release
bugs) my own survival while I am running. I tested this and it
appears to be true: you can do [[[NSURLConnection alloc]
initWithRequest: req delegate: self] release] and it will work just
fine. Of course, that is an odd piece of API, so it would probably be
better to have a class method that hid the instantiation of the object.
Anyway, if you want to have some other solution to NSURLConnection
callbacks and lifetime, feel free to implement that and report back,
in the meantime I will stick with my solution, which I like because it
works and doesn't make any unnecessary and potentially fatal
assumptions.
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
