Re: Bluetooth-dev Digest, Vol 7, Issue 13
Re: Bluetooth-dev Digest, Vol 7, Issue 13
- Subject: Re: Bluetooth-dev Digest, Vol 7, Issue 13
- From: Matthias Ringwald <email@hidden>
- Date: Thu, 29 Apr 2010 09:00:16 +0200
On 29.04.2010, at 08:11, David Giovannini wrote:
In BTnut, the first Bluetooth stack I was involved, we used separate threads for different Bluetooth layers and protocols, but in the end, the required thread synchronization was just creating unnecessary problems. In my new Bluetooth stack called BTstack ( btstack.org), the Bluetooth daemon runs in a single thread which can handle any number of clients. So far this seems to be the right choice, both for portability and for implementation ease.
Yes, I want that single dedicated thread for BT. Forcing the client of the BT library to share the same thread as BT service is the problem.
I would argue that this depends on the "contract" you provide for your library (also, I did not know you have to provide one in the first place).
E.g., BTstack uses unix domain sockets to handle communication between the clients and the single Bluetooth daemon. To support the domain socket, the Cocoa(Touch) implementation registers a CFSocket that is wrapped into a CFRunLoopSource and added to the main run loop. So although it is a library, the communication with the server is on the main thread - not that it would matter for socket communication, but it fits nicely with the pure select()-based runloop for non-GUI applications. The WiiMote OpenGL ES Demo ( http://www.youtube.com/watch?v=3FPHpMonoC8) is single-threaded without extra tricks.
Best Matthias
|
_______________________________________________
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