往Gatt characteristic写入数据时会将通道阻塞住

[Henxun]

Describe the bug
A clear and concise description of what the bug is.

Expected behavior
A clear and concise description of what you expected to happen.

Actual behavior
A clear and concise description of what actually happened.

Additional context
Add any other context about the problem here.

[Henxun]

let operation = self
.characteristic
.WriteValueWithOptionAsync(&writer.DetachBuffer()?, write_type.into())?;
let result = operation.await?;

代码阻塞 "let result = operation.await"，并且之前调用的discover_services也会阻塞无法结束

[Henxun]

当get_characteristics中调用GetCharacteristicsWithCacheModeAsync中传入参数BluetoothCacheMode::Uncached时会阻塞代码运行,BluetoothCacheMode::Uncached正常或者调用GetCharacteristicsAsync

[qdot]

This should be addressed by commit 758c10e — both GetCharacteristicsWithCacheModeAsync and GetDescriptorsWithCacheModeAsync now use a 5-second timeout on uncached mode, falling back to cached mode with a warning log if the uncached call hangs. This avoids the indefinite hang while still preferring fresh GATT data when possible.

[bpbradley]

This should be addressed by commit 758c10e — both GetCharacteristicsWithCacheModeAsync and GetDescriptorsWithCacheModeAsync now use a 5-second timeout on uncached mode, falling back to cached mode with a warning log if the uncached call hangs. This avoids the indefinite hang while still preferring fresh GATT data when possible.

I know this is old, but just resurrecting here where I think this is most relevant --

But I am noticing that the fix linked here is causing issues on devices which have a modest number of services / characteristics (as in, more than just a few), on Windows.

Basically, it appears to hang forever. I was able to get it to eventually connect and read services, but it takes multiple minutes for about 15 characteristics.

Briefly looking, it seems the uncached enumeration was timing out, and then falling back to cache mode which would also hang. It seems that the abandoned WinRT operation might hold internal locks that block subsequent GATT operations. So each async read is queueing behind a stuck operation, and so individual characteristic reads were taking ~5 seconds each, adding up to 30+ seconds just to read a handful of values. This adds up pretty quickly if you are trying to read data from a few characteristics.

My only real workaround right now was to bypass btleplug for GATT on windows, using windows crate to call WinRT BLE APIs directly. Each read/write opens a fresh BluetoothLEDevice via FromBluetoothAddressAsync and queries the specific service/characteristics needed using GetGattServicesForUuidAsync + GetCharacteristicsForUuidAsync with default cache mode. This method gives me instant reads.