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: Fri, 30 Sep 2005 17:38:19 -0700
All Bluetooth calls must occur from the same thread. It is not
thread safe and there are many run loop event sources that get added
by the framework that must all be on the same run loop.
Fortunately all of the APIs have asynchronous versions. You really
don't need multiple threads to do many things at once. Just issue an
async call and go about your business. When the operation is
complete, your callback (or delegate) will be called (assuming you're
not blocking that run loop - which you likely won't be if you're
using all async operations).
If you really need multiple threads for other reasons, you're
probably best off doing those other operations on a new thread and
then signaling to the main thread when that work is done. The method
-performSelectorOnMainThread:... is very useful for things like that
although there are plenty of other mechanisms you can use as well.
The other benefit of this design is that you'll never be blocking
your main thread, so your UI is always available to the user.
- Eric
On Sep 30, 2005, at 5:19 PM, Joseph Kelly wrote:
So what are my threading options again? IOBluetoothXXX works from
any thread so long as its invoked from the same thread? Can inquiry
be invoked from a different thread than device/channel operations?
My requirement are thus: I need to perform the inquiry on a
separate thread, but the connect/disconnect/read/write could be
invoked synchronously from any arbitrary thread, most likely not
the main thread.
My thought is I will need a special monstro-bluetooth thread that
does everything. Now wait, hold on. What happens if my thread is
doing a pthread_cond_wait() (or NSConditionLock?) on a queue or
something, and the channel gets some incoming data or NSTimer
fires, then will the delegates ever get called?
joe
On Sep 29, 2005, at 5:20 PM, Marco Pontil wrote:
Because RFCOMM implements a flow control, there is the possibility
that the other side does not empty its queue blocking the data
send. So it is possible that data does not go over the air (and
you do not get a notification for it).
This is really an unlikely event, but if you think it can happen
starting a NSTimer may be worth doing.
... Marco
On Sep 29, 2005, at 5:07 PM, Joseph Kelly wrote:
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?
None so far. I'm just planning for the worst-case.
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.
Thanks. I'm still deciding exactly how to arrange my code. I'm in
a bind that I must design my bluetooth code to plug into a cross
platform application that's expecting a particular interface and
also be exported as a bundle that's loaded into a CFM application.
joe
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Bluetooth-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40apple.com
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
_______________________________________________
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