site_archiver@lists.apple.com Delivered-To: bluetooth-dev@lists.apple.com But here are some hints: joe On Nov 16, 2005, at 2:48 PM, Geoffrey Schmit wrote: CFRunLoopRunInMode( kCFRunLoopDefaultMode, timeout, false ); CFRunLoopRef runLoopRef = CFRunLoopGetCurrent(); CFRunLoopStop( runLoopRef ); which returns control to the read method which then returns the data. Is this a reasonable approach? 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/joeman%40mac.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... Oh would that Apple have developed a Bluetooth framework that was thread-safe! It is absolutely not advisable to use a dedicated worker thread to call the Bluetooth api's. It's unreliable, and you won't even be able to use IOBluetoothUI.framework. I've developed a program model in which the main thread performs Bluetooth operations at the behest of other threads which post requests in a queue which the main thread reads. The api I present to the client thread specifies that the operation be synchronous, thus my request object contains a conditional mutex which blocks until the main thread is done with the operation. Instead of having the main thread busy poll the queue (the queue itself is protected by a mutex), I set up a run loop source on the main thread which is triggered by the client thread when it adds the request object. The main thread wakes up, takes a request off the queue, and performs the indicated operation using the async Bluetooth apis whenever possible -- this lets the main thread handle multiple requests at a given timeframe. It got tricky when I tried to implement the requirement that the main thread could also call the api and expect to block. The workaround is to "pretend" to block, but not actually use the conditional mutex in the request object. Instead, add the command to the queue which triggers the source, and call CFRunLoopRun(), and in the completion routine, which would normally set the "completed" condition on the mutex, call CFRunLoopStop(CFRunLoopGetCurrent()). Hopefully you won't have to support CFM applications, but if that's the case, I've got more hints. 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: in the read method. In my RFCOMM event listener callback, I exit the run loop with: 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? This email sent to joeman@mac.com This email sent to site_archiver@lists.apple.com