Re: Blocking loops
Re: Blocking loops
- Subject: Re: Blocking loops
- From: "A.M." <email@hidden>
- Date: Fri, 16 Jun 2006 11:19:45 -0400 (EDT)
On Fri, June 16, 2006 10:41 am, Nicko van Someren wrote:
> On 16 Jun 2006, at 14:24, email@hidden wrote:
>
>
>> I've got an application that does a fair bit of processing in a
>> while loop...
> ...
>
>> Unfortunately, the progress bar doesn't actually move (and the App is
>> unresponsive) until the loop completes.
>
> There are two problems here. One is that the progress bar does not
> move; you can probably fix this by calling [progressBar display] to force
> the a redraw. The second problem is that your application has become
> unresponsive, which may still be a concern even if the progress bar lets
> the user know something is happening. In this case you might want to
> consider either moving the whole process to another thread or, given that
> you're looking at processing a large batch of objects, processing the
> objects one at a time by writing a method to be called back using
> something like performSelector:withObject:afterDelay: In this case you
> could pass the enumeration object in to your selector with a delay of 0.0
> and have the method trigger another call to itself if it managed to pull
> anything out of the enumeration this time around.
I have implemented a state machine for a network protocol based on
CFSocket. Theoretically, it never blocks the main thread on a system call.
However, the read callbacks completely monopolize the runloop making it
seem like it's blocking anyway.
My point is that, even when the implementation makes use of non-blocking
APIs, NSRunLoop still may not adequately respond to user interaction. Some
better heuristics (instead of round robin) in NSRunLoop would be
appreciated.
My options to alleviate this:
1) put the read callbacks in a separate thread
-CFSocket already uses a thread- why another?
2) use netclasses and implement throttling
3) try to fudge some read-callback throttling into CFSocket...
Anything else?
-M
_______________________________________________
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