Re: RFCOMM Channel Read/Write timeout strategy?
Re: RFCOMM Channel Read/Write timeout strategy?
- Subject: Re: RFCOMM Channel Read/Write timeout strategy?
- From: Eric Brown <email@hidden>
- Date: Thu, 29 Sep 2005 16:17:17 -0700
If you issue an RFCOMM write call, the data will be delivered unless
the connection is terminated. Unless there are horrible radio
conditions, it seems unlikely to take very long before the write
completes and you callback is called. Are you having specific
problems with writes taking too long to complete?
In answer to your question, your best bet is probably to create an
NSTimer with the timeout that you want. Then in your callback, yoou
can invalidate the timer if it hasn't fired. With that model, there
is no need to block your main thread. Either the timer will fire, or
you will get your write callback called.
- Eric
On Sep 29, 2005, at 4:09 PM, Joseph Kelly wrote:
Any idea on how to perform reads and writes with a timeout?
I was thinking of something like:
bool bTimeout = true;
[channel writeAsync... refcon:&bTimeout]
[currentThread sleep:timeout...]
if (bTimeout)
handleTimeoutError...
...
And in the async notification delegate:
if (status == okay)
*refcon = false; // i.e. flag that data was got okay
[currentThread wake]
I'm not sure if this is even possible or advisable (I've never used
Cocoa threading...)
Any ideas, including any timing guarantees made by Apple or
Bluetooth or RFCOMM? My timing constraints tend to be "as real time
as possible"... once again, is there a lower level api? ;-)
joe
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Bluetooth-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Bluetooth-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden