Apple

On Apr 29, 2010, at 2:00 AM, Matthias Ringwald wrote:

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).

Every library has implicit and explicit contracts. Forcing a threading model that eliminates the possibility to wait on a response is a contract that reduces usefulness (and could dramatically increase client code).

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.

Would it be possible to register the CFRunLoopSource into another thread's runloop?

Best
Matthias

References:
	>Re: Bluetooth-dev Digest, Vol 7, Issue 13 (From: David Giovannini <email@hidden>)
	>Re: Bluetooth-dev Digest, Vol 7, Issue 13 (From: Matthias Ringwald <email@hidden>)
	>Re: Bluetooth-dev Digest, Vol 7, Issue 13 (From: Matthias Ringwald <email@hidden>)