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: "dsjove .mac" <email@hidden>
- Date: Thu, 29 Apr 2010 09:14:35 -0500
On Apr 29, 2010, at 8:41 AM, Matthias Ringwald <email@hidden>
wrote:
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.
I am writing for the desktop using Cocoa's BT objects. I would love to
get this app on the iPhone but jailbreaking appears to be the only
option.
My model over BT is remote procedure calls. That is why I need a
dedicated thread for acquiring and signaling results.
"Blocking" is an ambiguous term. If an event on the main thread calls
a function, it is blocking. The low level private implementation
detail of a function interacting with BT is irrelevant to the fact
that the main run loop calls a getter on a model object. I have
policies built in for timeouts.
Some of these getters are computed from the results of multiple BT
remote procedure calls. The main thread calls the procedural getters.
In one connection implementation, BT, it uses another thread to sync
the results.
I would recomend allowing the client of your library to select the
thread. Auto injection into global state is a limiting side-effect.
RPC becomes very difficult.
So back to CocoaTouch - can your code go into an AppStore product?
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
| 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>) |
| | >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>) |