Re: Tight Runloop
Re: Tight Runloop
- Subject: Re: Tight Runloop
- From: Alastair Houghton <email@hidden>
- Date: Tue, 25 Sep 2007 14:29:12 +0100
On 25 Sep 2007, at 12:11, Ricky McCrae wrote:
The work needs to be performed is not thread safe and therefor
needs to be
performed on the current thread.
[snip]
someFunction communicates with another object and needs to wait for a
callback so its occupying itself while it waits for the callback
like so;
do
{
[[NSRunLoop currentRunLoop] runMode: NSDefaultRunLoopMode
beforeDate:[NSDate dateWithTimeIntervalSinceNow: 2]];
}while(somecondition);
The callback is processed and the condition is met, the UI receives
updates
but mouse events are not processed.
The problem with this kind of code is that the run loop doesn't
always work the way you expect (as you've discovered). You also run
the risk of having to deal with re-entrancy.
Basically, the problem you're having here is that you're trying to
mix event-driven programming with linear blocking programming. The
two don't really mesh together very well, so it's better either to
put your blocking code on a separate thread, or write all of your
code in an event-driven fashion.
It's normally *much* easier to farm the work off to a separate
thread, then just have the thread inform the main thread when it's
done. What are you actually doing in your code that you feel can't
be done that way? Remember, "thread safety" *normally* refers to the
ability of code to run simultaneously on more than one thread, not to
whether it can be invoked at all from a separate thread. Code that
can't run *at all* on a separate thread does exist but it's very much
less common.
Kind regards,
Alastair.
--
http://alastairs-place.net
_______________________________________________
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