On Mar 11, 2004, at 1:09 PM, Crichlow, Eric wrote:

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.

I'm filing a bug report that the current API doesn't provide a mechanism to control the run loop modes that the incoming Bluetooth events are handled in. It sounds like that would have helped you here.

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?

The problem is that in a number of cases, you need a mechanism to both determine what devices are already connected and be notified about new ones. Instead of providing separate APIs to handle this, a single API was provided to do both. This also gets around a race condition where if you asked for the existing connections, then registered for new device notifications, you could miss one if one came in at just the right time. In that case, you'd have to register the notification first and then ask for the existing connections possibly resulting in the same device being reported twice. The current API doesn't have that limitation. When the initial notification is registered, the caller is notified about all existing connections. Then as new connections are established, new notifications are sent. - Eric [demime 0.98b removed an attachment of type application/pkcs7-signature which had a name of smime.p7s] _______________________________________________ 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.