• 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: Bill Bumgarner <email@hidden>
  • Date: Fri, 16 Jun 2006 10:27:56 -0700

On Jun 16, 2006, at 8:19 AM, A.M. wrote:
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.

That'll only happen if the number of events coming in through the network port are arriving fast enough such that the event loop doesn't have enough time to service user events. Or, potentially, if you are not exhausting all possible data from the socket with each read.


It sounds like a potentially very chatty network protocol. If you own the protocol, is there a way you can modify it to reduce the # of packets and/or amount of data?

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.

I'm not sure that would help. Prioritizing user events over network events would just lead to stalls or dropped data on the network side; buffer overruns, that kind of thing.


My options to alleviate this:
1) put the read callbacks in a separate thread
  -CFSocket already uses a thread- why another?

CFSocket uses a single additional thread to handle I/O across all CFSockets. A common unix-y idiom.


You would then push the processing of the data into your own thread (with its own runloop). That way, the processing of the data won't block additional CFSocket low-level event processing as it'll be on a separate thread.

If you want to maximize throughput, this is likely the best strategy.

As per throttling, I don't know enough about such implementations to make any useful recommendations.

b.bum
_______________________________________________
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: "Michael Ash" <email@hidden>
    • Re: Blocking loops
      • From: "A.M." <email@hidden>
    • objectFileHasPlusLoadMethod
      • From: Craig Altenburg <email@hidden>
References: 
 >Blocking loops (From: email@hidden)
 >Re: Blocking loops (From: Nicko van Someren <email@hidden>)
 >Re: Blocking loops (From: "A.M." <email@hidden>)

  • Prev by Date: Re: MMICrashReporter - advance preview available
  • Next by Date: objectFileHasPlusLoadMethod
  • Previous by thread: Re: Blocking loops
  • Next by thread: objectFileHasPlusLoadMethod
  • Index(es):
    • Date
    • Thread