Noble.stop() sometime hangs

[Apollon77]

Analysis
I analyzed the “noble hangs on stop” a bit further. It is correct that I can not repro it with the original peripheral explorer you proposed, but in fact what I saw while comparing things is the following:
When I cann “stop” then this calls “stopScanning” internally. This call does not check if scnning is already stopped but just write

hci set scan enabled - writing: 010c20020001 +7ms

to disable it. I saw that in the code of noble there is formally nothing waiting for a response, but in the C++ code there is that polling loop where “stop” waits for to exit.
Now … in all cases where it “Blocks” the last log is this write from “hci” (ok and a “scanStop log from “noble”).
In cases like the explorer or also for me when it by chance does not block after that above write there is another “onSocketData” … so incoming data.
The incoming data is either

hci onSocketData: 040e04010c200c +32ms
hci event type = 4 +1ms
hci sub event type = 14 +0ms
hci cmd = 8204 +0ms
hci status = 12 +0ms
hci result = +0ms

or

hci onSocketData: 040e04010c2000 +32ms
hci event type = 4 +1ms
hci sub event type = 14 +0ms
hci cmd = 8204 +0ms
hci status = 0 +0ms
hci result = +0ms

… so according to ChatGPT it is a “command complete” message
So could it be that he expects still some kind of data to be received in the cases where it blocks? (bearbeitet)

** Reproduction**
And here is the repro instructions for the “peripheral-explorer.ts” example … just wait a bit before stop().

So add a

await new Promise(resolve => setTimeout(resolve, 3000));

directly before the “noble.stop()” call … and the stop hangs reliably for me.
Seems that by high chance there is something coming in when you do all after each other, so that a package comes after calling stop. Ok a CTRL-C fixes that then but it does not end itself

Workarounds
I can also reliably solve it by calling "startScanning()" directly before stop() which then ensures that data is returned. This makes sure that some data are incoming when stop is called. A hack but works. Other option is to e.g. do a "this._hci.readLocalVersion()" just before the stop. This serves the same purpose.

Thoughts for real fix
My current assumption (ok as non c++ dev it is not more) is that the issue is within the hci-socket library. When I assume right then https://github.com/stoprocent/node-bluetooth-hci-socket/blob/8d28eb160cf4cc13580d2d29cc394d885fc74006/src/BluetoothHciSocket.cpp#L45 should block until data are available, which might not be the case and so it waits until one more set of incming data are present. And stop is waiting for the read loop to end

https://github.com/stoprocent/node-bluetooth-hci-socket/blob/8d28eb160cf4cc13580d2d29cc394d885fc74006/src/BluetoothHciSocket.cpp#L596

right?

[stoprocent]

hey @Apollon77 i've tested with await new Promise(resolve => setTimeout(resolve, 3000)); and it works as expected. Not sure how to reproduce

[Apollon77]

I tried that on a raspi? In fact for me it is the case that it will hang as soon as he expects data to come in in the data read loop. If it gets stopped he also just "not listen again" after the current read got finished with some data.

I just tried it again on my raspi and It still reliably hangs for me the above described way.

[wwaaijer]

Was able to reproduce, but only on a Raspberry PI 3, most likely due to the slower CPU🤔
Can also confirm it's the blocking read call which is causing the issue, it's waiting for "one more message".

The timings seem to be very unlucky.
Internally there is a "stopScanning" command sent when noble.stop() is called.
On the PI 3, the answer to that command is already received by the time hci.stop() is called.
Other systems seem to be fast enough that hci.stop() is timed before the answer is received, causing the answer to unblock read.

I'm opening up a PR with a proposal