You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In gatt.go/Connect, once Scan has been called, it looks as though incoming adverts will create goroutines that eventually call fn to pass the advert data to Dial via ch. If multiple adverts arrive quickly, Dial will process the first, but the remaining adverts will block in fn on the send to ch.
Similarly, if Scan terminates for any reason other than a cancel, then we don't reach Dial and an incoming advert could block when trying to send to ch.
These blocked sends could leak goroutines, so Connect should probably close ch before the two return paths exit, and fn could defer a call to recover, in order to handle any panics when a is sent to a ch that's been closed.
The text was updated successfully, but these errors were encountered:
In gatt.go/Connect, once Scan has been called, it looks as though incoming adverts will create goroutines that eventually call fn to pass the advert data to Dial via ch. If multiple adverts arrive quickly, Dial will process the first, but the remaining adverts will block in fn on the send to ch.
Similarly, if Scan terminates for any reason other than a cancel, then we don't reach Dial and an incoming advert could block when trying to send to ch.
These blocked sends could leak goroutines, so Connect should probably close ch before the two return paths exit, and fn could defer a call to recover, in order to handle any panics when a is sent to a ch that's been closed.
The text was updated successfully, but these errors were encountered: