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 15:41:58 +0200
Hi David
interesting software architecture discussion... :)
On Apr 29, 2010, at 2:10 PM, David Giovannini wrote:
>
> 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).
Yup. I do agree here, however, e.g., the Cocoa(Touch) Framework already requires "no blocking, all user interface operation on the main thread". If Apple then says: "all your Bluetooth communication has to be on the main thread, too", it does not restrict the rules set up by the Cocoa Framework any further. So, if rules for apps are already set by the OS, your library would not restrict anything by saying it must be started from the main loop and the main loop cannot block.
>>
>> 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?
Are you asking about BTstack? If yes: the BTstack client library does not provide a way to choose a run loop, but as it is only using thread-safe socket functions, that could run on any given thread. If there is a clear need for such a feature, I would't mind adding a "set default runloop" function. Would that help you in any way?
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