Re: NSURLConnection dependency on RunLoop (Sanity check)
Re: NSURLConnection dependency on RunLoop (Sanity check)
- Subject: Re: NSURLConnection dependency on RunLoop (Sanity check)
- From: Andrei Tchijov <email@hidden>
- Date: Thu, 21 Jul 2005 19:31:29 -0400
j o a r,
Thanks for prompt response. I did run into this problem while
writing Unit Test case for my code (so it is "command line" based
situation). I do appreciate that the code in question, most likely
will work just fine in GUI environment (without creating new
threads). On other side, the whole idea or "RunLoop" looks very
archaic. This is how things used to be programmed before threads
were invented. It will save you from creating extra thread now and
then, but is it such a big deal now? If my program "express desire"
to connect to particular URL it should be no one business what else
it is doing in the same thread. It is asynchronous call after all.
Andrei
On Jul 21, 2005, at 17:28, j o a r wrote:
On 21 jul 2005, at 21.23, Andrei Tchijov wrote:
NSURLConnection when used in asynchronous mode
( initWithRequest:delegate: ) starts couple threads to deal with
actual IO but also register some inputs with RunLoop of the thread
which created it. As a result, nothing will happen with such
connection until that RunLoop had a chance to "run" (at least none
of delegate methods are going to be invoked).
That sounds about right.
The way I solved this problem (feature) is by creating new thread
each time I need to use NSURLConnection. Is there a better way?
What is your main thread doing? Why is it so busy? Usually you try
to keep the main thread idle as much as possible, to allow it to be
responsive to user events. But perhaps you're talking about some
sort of command line utility?
Yes, you *could* of course solve the problem with a second thread,
but it kind of defeats the whole purpose of this design. The point
is that you shouldn't have to set up these extra threads yourself,
and figure out how to communicate between them.
j o a r
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden