Re: IOBluetoothRFCOMMChannel and NSThread
Re: IOBluetoothRFCOMMChannel and NSThread
- Subject: Re: IOBluetoothRFCOMMChannel and NSThread
- From: Marco Pontil <email@hidden>
- Date: Mon, 3 May 2004 14:33:36 -0700
Yann,
all UI calls need to be made on the main thread (this is an Appkit
restriction) and all Bluetooth calls need to be made on a single
thread. So This pretty much means that if you need to use Bluetooth and
UI on a thread, all the calls need to be made on the main thread. Using
the asyncronous APIs you will avoid blocking the UI for lengthy
operations (like connections).
Also I would like to point out that trying to connect every 10 seconds
is a very bad idea. The connection require the connecting device to
cover the 2.4Ghz band to find the counterpart which means that you will
disrupt AirPort networks. In general this is not that bad because it
does not happen that often (only when you connect) and 802.11 can
recover by re-sending its packets, but if you try to connect every 10
seconds you give very little room for the AirPort network to recover.
If you really need to "keep trying" I would suggest attempts between 30
seconds to one minute (the longer the interval, the better).
... Marco
On May 3, 2004, at 1:42 PM, Yann Bizeul wrote:
Thanks for the answer.
In fact I started to establish a thread responsible of all bluetooth
stuffs. Worked not so bad but it seem some bluetooth operations stick
other ones.
For example, while I'm trying to connect every 10s to a device, If I
try to get pairedDevices to display preferences, this method returns
nothing.
Is there a rule for those stuffs ? I'm doing all bluetooth calls in
the same thread.
Right now I'm trying to use IOBluetoothUI to get a device in the
prefs, but the windowController stays white, hangs the app, and
display nothing.
Is there a difference between using AppKit thread or a custom one ?
Any idea ?
Thank you !
Le 3 mai 04, ` 19:05, Marco Pontil a icrit :
Hello Yann,
The problem is that the Bluetooth Stack is not designed to run on
multiple threads. The first thread that makes a call in the stack is
also the only thread that will receive events (and new data is an
event) from the stack.
Since your problem seems to be the connection blocking I would
suggest to use the asyncronous API to open the connection. In this
way the caller will not block and once the open connection is
completed will be notified of the results (success or failure).
... Marco
On May 2, 2004, at 2:04 AM, Yann Bizeul wrote:
--
Yann Bizeul - yann at tynsoe.org
http://projects.tynsoe.org/
_______________________________________________
bluetooth-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/bluetooth-dev
Do not post admin requests to the list. They will be ignored.