FWIW, that's exactly what AsyncSocket does, using delegate callbacks (pretty typical Cocoa pattern). This is one reason why I suggested it.
On Wed, Jan 20, 2010 at 3:06 PM, nicolas berloquin <cepak...@gmail.com>wrote: > I may not have fully grasped your problem but you seem to say that getting > 'pieces' of the reply generates a lot of problems for you. > Couldn't you have a socket that buffers the replies and that sends the > whole aggregated messages to the rest of the app when done ? > You could have a special 'message' sent by the server to let you know that > it's done sending or (if it can know beforehand how much will be coming) > One thing you could look at are notifications. They're very easy to use and > are a cool way to send data around an app (locally) asychronously or from > background threads. > > > Le 20 janv. 2010 à 21:09, Ken Thomases <k...@codeweavers.com> a écrit : > > On Jan 20, 2010, at 1:42 PM, Carter R. Harrison wrote: >> >> On Jan 20, 2010, at 2:23 PM, Ken Thomases wrote: >>> >>> If you're using lots of CPU time, then you're not blocking, you're >>>> spinning. When a thread is blocked, it does nothing and consumes no CPU >>>> time. >>>> >>>> Now, blocking is bad in the main thread of a GUI app, but if you're >>>> writing non-GUI code, it can be a perfectly sensible design approach. >>>> However, you have to actually implement blocking! >>>> >>> >>> Ken - thanks for the info. I had thought the same thing when I wrote the >>> code so I must be doing something wrong as you said. Here's my method that >>> sends data and then waits for the response back from the server. I've >>> paired my code down so it is a bit simpler than it actually is, but the gist >>> of it is the same. Here the request is sent to the server and the method >>> does not return until 1024 bytes of data has been returned. I'm basically >>> calling [NSInputStream hasBytesAvailable] and if it returns NO then I am >>> using the sleep() method to sleep the thread for 100ms. Over a fast >>> connection the CPU usage is very very low (< 2%), but on a slower connection >>> where the server could take a couple hundred milliseconds to return the CPU >>> usage hovers around 25 or 30% - way too high for regular use. In the code, >>> "is" is an NSInputStream and "os" is an NSOutputStream. I would greatly >>> appreciate your insight on this. >>> >> >> First, you're not sleeping for 100ms. sleep() takes an integer number of >> seconds. You're passing .1 which is getting truncated to 0. So, you're >> calling sleep(0). That may not be a total no-op -- the kernel will probably >> yield your time slice to another process or thread -- but it doesn't block >> your thread. >> >> Second, you need not invoke -hasBytesAvailable. Just invoke >> -read:maxLength:. That will block if no data is available. >> >> Cheers, >> Ken >> >> _______________________________________________ >> >> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) >> >> Please do not post admin requests or moderator comments to the list. >> Contact the moderators at cocoa-dev-admins(at)lists.apple.com >> >> Help/Unsubscribe/Update your Subscription: >> http://lists.apple.com/mailman/options/cocoa-dev/cepakare%40gmail.com >> >> This email sent to cepak...@gmail.com >> > _______________________________________________ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/cocoa-dev/steven.degutis%40gmail.com > > This email sent to steven.degu...@gmail.com > -- Steven Degutis http://www.thoughtfultree.com/ http://www.degutis.org/ _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
