-
Notifications
You must be signed in to change notification settings - Fork 163
Description
I'm trying to facilitate simple connections to BLE devices in a relatively noisy BT environment, and am getting occasional failures to connect. This isn't terribly surprising to me, however the Darwin gap code has some behavior that causes my application to stall irrecoverably.
Specifically, it seems that the implementation of adapter.Connect()
relies on ConnectionTimeout to only trigger CoreBluetooth's cancelPeripheralConnection
- however, it then blocks forever waiting for a positive disconnect signal from the CoreBluetooth stack. In my case, I never see this signal come in; and since the timeout has already been waited on, we stay blocked forever. My guess is that cancelPeripheralConnection
does not reliably fire back didDisconnectPeripheral
in all connecting states
A couple of thoughts
- if ConnectionTimeout is going to be consumed to trigger a disconnect, there needs to be a way to time-bound the actual 'disconnect'-ing part.
- it would be nice if
adapter.Connect
could rely on a context for better cancel propagation. In this case, perhaps a context could be used to guard the forever-waiting case and ConnectionTimeout can remain as-is.