Re: Blocking loops
Re: Blocking loops
- Subject: Re: Blocking loops
- From: Agent M <email@hidden>
- Date: Sat, 17 Jun 2006 14:53:29 -0400
On Jun 17, 2006, at 11:31 AM, Michael Ash wrote:
On 6/16/06, Bill Bumgarner <email@hidden> wrote:
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?
This is not really a good solution. You must always assume that the
other end of your communications pipe is inhabited by a malevolent
force. If the only thing stopping your program from becoming
unresponsive is voluntary throttling, then it's trivial for that
malevolence to perform a denial of service on your application.
> 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.
Networks are inherently unreliable, and therefore any protocol running
on one must be engineered to deal with all of the problems you
mentioned anyway. It's better to stall or drop data on something that
can deal with it than to present a frozen interface to the user.
That said, doing your network IO on a separate thread is a good idea
if you want to deal with high-throughput data. You will get fewer of
the aforementioned stalls and no GUI freezes, and in addition to that
you'll be in good shape to take advantage of multi-CPU machines, which
is particularly nice now that almost every new Mac has at least two.
Thanks for the response. In fact, the network IO already is in another
thread- that is how CFSocket operates (and blocks). I expected that
because I never block on a syscall, that the UI would be serviced
appropriately but I found that it is not the case. So now my only real
option is to move the protocol parsing/constructing code into its own
thread.
At some level there will need to be some throttling- I would like the
user to be able to use the UI while megabytes of database query results
are streaming in and are being displayed live in a table view. Right
now, I manually update the table view and surrounding info but I have
to call -display or the UI never gets serviced and I get the beachball
after a while.
¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬
AgentM
email@hidden
¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬
_______________________________________________
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