Re: Does CFSocket use efficient polling?
Re: Does CFSocket use efficient polling?
- Subject: Re: Does CFSocket use efficient polling?
- From: Josh Graessley <email@hidden>
- Date: Thu, 12 Feb 2009 13:29:55 -0800
On Feb 12, 2009, at 1:07 PM, Joel Reymont wrote:
On Feb 12, 2009, at 8:50 PM, Josh Graessley wrote:
In my experience, there are two good reasons to use a thread:
1) You're CPU bound so you need to utilize multiple cores
2) You're using a poorly designed API - synchronous APIs are a good
example
I'm with you Josh! How do I get notified that there's data to be
read from a socket _without_ using a separate thread and without
busy-polling?
I don't know if CFSocket allocates a single buffer and reuses it,
for example.
I want to use a single buffer of an exact size and I don't need
NSData back.
It looks like I need to use the BSD socket API but I suspect that
checking the socket every time my audio playback callback is
triggered may not be optimal. I'd rather check the socket, receive
data and post it to a buffer outside of my audio callback.
Can this actually be done without using a separate thread?
Use CFSocket. It's working around the bad API for you. For now it
creates another thread because that's the only way to work around the
bad API. It isn't "busy-polling". The other thread will sleep waiting
for an event. When the bad API is fixed, CFSocket will switch to using
a good API and your code won't have to change.
When you setup the CFSocket, only enable the kCFSocketReadCallBack
event. When CFSocket notifies you that there's data on the socket with
a kCFSocketReadCallBack event, read data from the socket using the BSD
APIs. It's that simple.
-josh
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden