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.