site_archiver@lists.apple.com Delivered-To: bluetooth-dev@lists.apple.com joe On Oct 24, 2005, at 5:07 PM, Joseph Kelly wrote: I hope this is the last of my Bluetooth questions for a while ; ) joe _______________________________________________ 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 This email sent to joeman@mac.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... I just got rid of the synchronous calls altogether. It's all async now and it works great. My Bluetooth module is working under most circumstances, unfortunately, when I call openRFCOMMChannelSync:withChannelID:delegate:, I usually get kIOReturnNotOpen (0xE00002CD). I call openConnection: (also sync) on the device prior to opening the channel, and it returns no error. I'm building 2 test clients for my module (a bundle): one is Mach0, and one is CFM/WNE (ugh!). Both load the module as needed via CFBundle. The Mach0 client connects successfully to the device about 60% of the time. The CFM version, however, connects less than 5% of the time. The async methods seem to work okay (i.e. openRFCOMMChannelAsync:withChannelID:delegate: works about 90% of the time.) I also have a Mach0 app that includes the code directly, and the sync commands succeed 80% of the time. Any ideas here? Is there anything about the process/user space that would impede the timing of sync operations? The CFM/WNE app does have a bunch of timers on the run loop. It also uses MPTasks as the basis for its threading, but those are really just pthreads. This email sent to site_archiver@lists.apple.com