site_archiver@lists.apple.com Delivered-To: bluetooth-dev@lists.apple.com Hello: I have some code that communicates with a Bluetooth device using the RFCOMM protocol. The communication is very ordered -- that is, I typically send a command, then, wait for a response from my device, and then send the next command (as opposed to receiving data at unpredictable intervals from the Bluetooth device). I've created a callback and registered it using the IOBluetoothRFCOMMChannelRegisterIncomingEventListener function from IOBluetoothUserLib.h. This has been working fine for me since OS X 10.3.9. However, we recently noticed some strange behavior on newer MacBook Pros running OS X 10.5 (with a particular Bluetooth chipset? or maybe dual core?). Digging into the problem, I discovered the root cause was that RFCOMM events were arriving in my callback in an order I didn't expect. Typically the exchange goes something like this: 1. write data 2. receive kIOBluetoothRFCOMMChannelEventTypeWriteComplete 3. receive kIOBluetoothRFCOMMChannelEventTypeData 4. read data But in this situation, the order was: 1. write data 2. receive kIOBluetoothRFCOMMChannelEventTypeData 3. receive kIOBluetoothRFCOMMChannelEventTypeWriteComplete 4. read data, but with buggy behavior That seems counter-intuitive -- how can the response data be ready before the write has completed? I expected that a search through the documentation would find either (a) a guarantee that a write event will always complete before the new data event occurs, or (b) a warning that events can arrive out of order, so I should code carefully. Unfortunately, I didn't find any inforamtion about event ordering. (Closest was http://developer.apple.com/documentation/DeviceDrivers/Reference/IOBluetooth....) The happy ending is that we were able to resolve the problem just fine by being more careful about how we process the different events. But this seemed like strange enough behavior that I should expose it to a wider audience, if for no other reason than to serve as a caution to other developers. James Blair National Instruments 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