Okay, The combination of the Bluetooth system software not being thread safe and the "fact" (as far as I can tell, never got any confirmation or denial of this from anyone) that the rfcommChannelData callback doesn't get called while the app is running in NSEventTrackingRunLoopMode has caused me to go back to the drawing board and totally re-architect my app. Now I'm at another sticking point where things don't seem to work as expected, but maybe my expectations are just incorrect. I have any number of Bluetooth devices that may attempt connection to the computer. I handle this by initially starting a secondary (to my main application) app which sets up a Bluetooth service and then registers for notifications when a device initiates connection to that service. Once a connection is completed, the process unregisters from getting further notifications, and tells the main app to launch a new instance of the secondary app, which registers itself for any future incoming devices. The problem is, as soon as the next secondary app instance is launched and registers for a notification, it immediately gets called. But it's getting notified of the incoming device that already got handled (connected to) by the last instance of the secondary app. Once a device initiates connection to the computer, and an application completes connection to it, shouldn't the system NOT generate an incoming notification to any app that registers for such notifications AFTER the connection was completed? ...Thanx... ...Eric... _______________________________________________ bluetooth-dev mailing list | bluetooth-dev@lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/bluetooth-dev Do not post admin requests to the list. They will be ignored.