Re: Beachball on Lengthy Task
Re: Beachball on Lengthy Task
- Subject: Re: Beachball on Lengthy Task
- From: Pierce Freeman <email@hidden>
- Date: Sat, 04 Apr 2009 19:35:51 -0700
- Thread-topic: Beachball on Lengthy Task
Hey Dave:
Yeah, it really helped! I am trying to get the contents of the files in a
certain directory, so I think that I could probably get away with using a
timer. I assume you mean NSTimer for the timer, though there could be
another class that I am totally missing. ;) In addition, if you are to use
NSTimer, how would you suggest setting the timer to call another function
that requires a passed variable?
Thanks again.
On 4/4/09 7:27 PM, "Dave Keck" <email@hidden> wrote:
>> I am getting the beachball of death when I try to run an action that takes
>> over a few seconds to complete. Given, the beachball goes away after the
>> task is completed - But for lengthy tasks, why can't I just allow the user
>> to go along with their work instead of having them wait with the beachball?
>> Would this be a problem with memory management, or something else entirely?
>
> Something else entirely.
>
> User interface events (mouse clicks, typing, etc) are handled on the
> main thread. If you start performing a long task on the main thread,
> the main thread is blocked from reacting to any user events until this
> lengthy-task is complete. In more technical terms, while this long
> task is running, the main thread's run loop (the mechanism that helps
> handle UI events) cannot perform another iteration until your
> lengthy-function returns. (Note that the beachball appears when an
> app's main thread is blocked, as you've seen.)
>
> There are two ways I solve this problem: either create a separate
> thread, or use a timer.
>
> Creating a separate thread could be opening a can of worms, depending
> on how complex your app is. When using threads in your app, you must
> make sure that your threads communicate safely. If you choose to go
> the thread route, research "thread safety". There's around a
> bajillion+1 articles on the subject; of course, you should look for
> thread-safety articles written for the context of OS X/Cocoa. Also
> note that much of Cocoa is _not_ thread-safe, so the burden will often
> be on you to ensure that you're not using certain Cocoa classes
> incorrectly in regard to thread safety. (That is, using locks where
> appropriate, and not using certain classes or methods if they don't
> support multiple threads.) An excellent article on thread-safety and
> Cocoa can be found here:
> http://mikeash.com/?page=pyblog/friday-qa-2009-01-09.html
>
> On the other hand, you could use a timer. The idea behind a timer is
> you complete a small part of the task every time the timer fires,
> until the task is complete. In some respects, using a timer can be
> 'cleaner' than creating a separate thread: since a timer runs in the
> main thread, you don't have to worry about using locks everywhere. In
> other respects, using a timer can be much less elegant: you'll have to
> store the lenghty-task's state somewhere, so every time the timer
> fires, it knows where it left off. This can lead to some confusing and
> overall inelegant code, but sometimes can still be easier than
> creating a separate thread and dealing with the caveats of
> thread-safety. (And sometimes you simply can't use a separate thread,
> if something you rely on doesn't play nice with threads.)
>
> The route you choose really depends on how well your task can be
> self-contained. For example, if I'm calculating pi to ten billion
> digits, but want the UI to remain responsive, this is a perfect time
> to use a separate thread. On the other hand, if a lengthy task
> requires access to Cocoa classes that don't like threads (and the
> lenghty-task can be broken up into smaller chunks) then a timer may be
> a better choice.
>
> Hope this helps,
>
> David
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden