Re: Socket Blocking Question
Re: Socket Blocking Question
- Subject: Re: Socket Blocking Question
- From: Steven Degutis <email@hidden>
- Date: Wed, 20 Jan 2010 15:15:40 -0600
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 <email@hidden>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 <email@hidden> 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 (email@hidden)
>>
>> 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:
>>
>> This email sent to email@hidden
>>
> _______________________________________________
>
> Cocoa-dev mailing list (email@hidden)
>
> 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:
>
> This email sent to email@hidden
>
--
Steven Degutis
http://www.thoughtfultree.com/
http://www.degutis.org/
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden