site_archiver@lists.apple.com Delivered-To: bluetooth-dev@lists.apple.com I'm creating a framework that handles interactions with a Bluetooth device. While not too familiar with CFRunLoops, I've learned that they are integral to Bluetooth on Mac OS X. For example, in order for my RFCOMM event listener callback to be invoked, I need to ensure that the run loop is running. My framework presents a synchronous read method, so I handle this by invoking: CFRunLoopRunInMode( kCFRunLoopDefaultMode, timeout, false ); in the read method. In my RFCOMM event listener callback, I exit the run loop with: CFRunLoopRef runLoopRef = CFRunLoopGetCurrent(); CFRunLoopStop( runLoopRef ); which returns control to the read method which then returns the data. Is this a reasonable approach? I've also read that all interactions with the Bluetooth frameworks must be on the same thread. However, my framework is designed to be multi-thread safe and to be called by the application with a variety of threads. As expected, if the application invokes my framework with a variety of threads, the above approach doesn't work; the RFCOMM event listener callback is not invoked and the CFRunLoopRunInMode function returns immediately and reports that the run loop has no source or timers. If I restrict the application such that it only calls my framework on the applications UI thread, everything appears to work. However, this has some undesirable side effects. If I restrict the application to always calling my framework with the same thread, but have that thread not be the same thread that the application uses for UI, is this sufficient? Alternatively, if I want to continue to allow the application to invoke my framework with a variety of threads, can I create a single thread in my framework that manages all Bluetooth communication and then dispatch messages between this dedicated thread and the application's threads? Can this dedicated thread be a normal "naked" pthread? Any advice would be appreciated. Thanks! geoff -- Geoffrey Schmit Senior Software Engineer National Instruments geoffrey.schmit@ni.com www.ni.com _______________________________________________ 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... This email sent to site_archiver@lists.apple.com