Re: Blocking loops
Re: Blocking loops
- Subject: Re: Blocking loops
- From: "A.M." <email@hidden>
- Date: Fri, 16 Jun 2006 13:59:37 -0400 (EDT)
On Fri, June 16, 2006 1:27 pm, Bill Bumgarner 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?
It's the postgresql backend protocol and I am receiving result sets. I was
hoping to display the results in the table view as they stream in.
>> 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.
Well, it could be a form of auto-throttling what the app can handle- this
is TCP, so the kernel socket buffer would fill up and start dropping
packets and throttling back but that would be handled transparently. But
you are right that NSRunLoop wouldn't necessarily know what ideal rate is.
>
>> 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.
I am just disappointed because I spent a lot of time implementing the
non-blocking protocol and I will have to throw it into another thread- so
I could have used a blocking API anyway...
Thanks.
-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