• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Blocking loops
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

  • Follow-Ups:
    • Re: Blocking loops
      • From: Bill Bumgarner <email@hidden>
References: 
 >Blocking loops (From: email@hidden)
 >Re: Blocking loops (From: Nicko van Someren <email@hidden>)

  • Prev by Date: Re: Blocking loops
  • Next by Date: Re: Apple's Secret Desktop Sauce
  • Previous by thread: Re: Blocking loops
  • Next by thread: Re: Blocking loops
  • Index(es):
    • Date
    • Thread