Re: Blocking Method Return
Re: Blocking Method Return
- Subject: Re: Blocking Method Return
- From: Shawn Erickson <email@hidden>
- Date: Thu, 1 Dec 2005 14:10:53 -0800
On 12/1/05, Josh Ferguson <email@hidden> wrote:
>
I'm currently writing a library that implements some asynchronous networking code and performs a series of tasks. I want the entrypoint for this library to be synchronous - so that the method doesn't return until all the networking is done. Here's my specific scenario:
>
>
1.) Third party app calls into -[MyController method1]
>
>
2.) -method1 creates an asynchronous NSURLConnection and downloads some data
>
>
3.) Because NSURLConnection is asynchronous (which I need for progress updates), method1 returns immediately.
>
>
Step 3 is what I need to change. I don't want my method1 to return until all the asynchronous networking is done.
This implies you want to block (or possibly spin in) the thread that
called your "method1" down in "method1" until some asynchronous
operation completes.
>
To complicate matters, there's also UI involved (a WebView may be displayed). How do I go about blocking method1 until we're completely finished, without blocking the entire thread?
You may want to grab a book or review online resources on threads
since the above question doesn't make sense. :)
A thread is either running (executing or waiting to be scheduled) or
blocked. The thread will run the sequence of instructions that it is
presented with. In this case some call graph resulted in your method1
being called by this thread, the thread will either have to block in
your method1 or spin (remain running) in your method1 if you don't
want to return out of method1 until your asynchronous operation
completes.
If the thread that called method1 is the main thread of the
application (assuming a standard Cocoa application) then blocking this
thread will stall the processing of events for this application. If
stalled long enough you will see the spinning beach ball and/or the
application will respond poorly to users. If you document that method1
of library will block then callers should take steps to ensure that
the main thread isn't used to call this method.
Also if your code is depending on the main thread (having its runloop
going) then blocking could prevent notification of completion of your
asynchronous operation and/or prevent any UI you display from
functioning.
Another option is to spin in your method1 in a way that allows it to
potentially process events. You could do this by getting the threads
current runloop ([NSRunLoop currentRunLoop]) and then run that runloop
(runloops are basically a glorified loop, in other words they spin).
You would want to document this behavior to callers since it is a
little abnormal todo.
>
I'm sure there's a simple answer - I'm just not sure at all how to tackle the problem.
It will be hard to answer fully and correctly without a better
understanding of what you are doing.
For one I am confused on what you mean in above about your library
having a UI... basically I am not sure how your library is expected to
be used by a third party.
_______________________________________________
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