Re: Blocking loops
Re: Blocking loops
- Subject: Re: Blocking loops
- From: Bill Bumgarner <email@hidden>
- Date: Mon, 19 Jun 2006 16:06:21 -0500
On Jun 17, 2006, at 1:53 PM, Agent M wrote:
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.
No -- the data is received in a secondary thread, but you were
parsing/constructing in the MEL. Depending on the rate of data
arriving, this could be quite a significant number of additional
events in the MEL. Combined with the extremely low latency demands
put forth by the fleshy deity driving your program, the induced
latency in responsiveness is unnacceptable.
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.
Very likely -- I'm fully aware of the hostilities of networked
environments as per Mike's descriptions. Heed his words well...
This sounds like a rather demanding application in terms of network -
> display load. Even with the processing in a secondary thread, the
drawing is typically still going to be done in the MEL and you are
still going to have problems unless you are really, really careful.
If there is a need to edit in the same view that is also receiving
events, getting all of the event handling correct will be difficult.
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