When notifications are enabled on a DeviceCharacteristic on Linux, it starts a new goroutine listening on a channel for DBus signals, but when a device disconnects (or when EnableNotifications(nil) is called), the c.property channel is never closed, so the goroutine will keep waiting for a signal on its property channel.
In the case of EnableNotifications(nil), the goroutine will sleep forever and the signal will never come due to the call to RemoveSignal here:
|
c.adapter.bus.RemoveSignal(c.property) |
However, when a device disconnects, RemoveSignal is never called, so when a new notification handler is added to that characteristic after the device reconnects, the MatchSignal is re-added, so the old goroutine starts receiving signals again and executes its old handler, causing duplicated events and other undesirable issues.
When notifications are enabled on a
DeviceCharacteristicon Linux, it starts a new goroutine listening on a channel for DBus signals, but when a device disconnects (or whenEnableNotifications(nil)is called), thec.propertychannel is never closed, so the goroutine will keep waiting for a signal on its property channel.In the case of
EnableNotifications(nil), the goroutine will sleep forever and the signal will never come due to the call toRemoveSignalhere:bluetooth/gattc_linux.go
Line 282 in 12b6f0b
However, when a device disconnects,
RemoveSignalis never called, so when a new notification handler is added to that characteristic after the device reconnects, theMatchSignalis re-added, so the old goroutine starts receiving signals again and executes its old handler, causing duplicated events and other undesirable issues.