Re: How are incoming connections handled?
Re: How are incoming connections handled?
- Subject: Re: How are incoming connections handled?
- From: Eric Brown <email@hidden>
- Date: Thu, 11 Mar 2004 14:50:52 -0800
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 | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/bluetooth-dev
Do not post admin requests to the list. They will be ignored.