site_archiver@lists.apple.com Delivered-To: bluetooth-dev@lists.apple.com Hi all, Thanks in advance for any help possible. b ******************** Brian M. Criscuolo Lead Software Engineer Mark/Space, Inc. bcriscuolo@markspace.com <http://www.markspace.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... Realizing the list traffic is pretty low, I thought I'd give this one a try anyway. We have some old(er) code that deals with Bluetooth RFComm connections in a weird and probably a not-altogether correct way, but its been working for years successfully. In the past (Tiger and Leopard) we were handling rfcommChannelData delegate callbacks on a secondary thread - which allowed a blocking open-source library to be able to read data off of a queue as rfcommChannelData pushed the data received in. Now, in Snow Leopard, this isn't working - all delegate and notification callbacks from IOBluetooth are happening on thread 1 (the main thread), which means that our code isn't working. I suspect that what we're seeing is the correct behavior from IOBluetooth - comments here and there (including one from Jason Giles) point to the fact that IOBluetooth isn't thread safe and should be running entirely on the main thread. My question: how much has the inter-thread operation of IOBluetooth changed in Snow Leopard, and is what I'm seeing expected behavior? There is pretty much no discoverable information about the thread safety of IOBluetooth, unfortunately. Synchronize: Palm Prē | iPhone | BlackBerry | Windows Mobile | Palm OS | Symbian | Android | PSP | Macintosh | Windows This email sent to site_archiver@lists.apple.com