Re: Blocking loops
Re: Blocking loops
- Subject: Re: Blocking loops
- From: "Michael Ash" <email@hidden>
- Date: Sat, 17 Jun 2006 11:31:57 -0400
On 6/16/06, Bill Bumgarner <email@hidden> wrote:
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?
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.
Mike
_______________________________________________
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