site_archiver@lists.apple.com Delivered-To: bluetooth-dev@lists.apple.com 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: So back to CocoaTouch - can your code go into an AppStore product? Best Matthias _______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/bluetooth-dev/site_archiver%40lists.a... On Apr 29, 2010, at 8:41 AM, Matthias Ringwald <mringwal@inf.ethz.ch> 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. 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? This email sent to site_archiver@lists.apple.com