Open zevv opened 7 months ago
If things are going wrong in the kernel, there isn't much we can do in Bleak. I would suggest logging Bluetooth traffic with btmon
and reporting the issue to the folks that wrote the kernel driver for whichever bluetooth adapter you are using.
As far as I know, this should abide to all the rules:
do not connect while scanning do not perform connects in parallel
Where do these rules come from?
do not perform connects in parallel
Is this covered by always using await
with await client.connect()
?
In your code it is possible that the event loop runs await client1.connect()
followed by await client2.connect()
. With each operation in a different task.
Where do these rules come from?
I think I gathered these from various comments and examples throughout the project. Please correct me if any of those are wrong or not true.
Is this covered by always using await client.connect()?
Yes. As far as I understand my own code, await client1.connect()
needs to finish before await client2.connect()
can ever happen; the main poller keeps track of any in-progress connects with the self.busy
flag. Only after await client1.connect()
finishes JK.,poll
will return, and another client connect can be tried.
Anyway, I have abandoned any attempts to parallelize my polling, as I'm already having a hard time to get this to work reliably in a strictly serial way, see issue #1507...
What does self.busy
do? It is only set to None
in your snippet.
Your snippet does the following.
start = [await for poll] -> add aux to event loop -> repeat start
aux = [await for poll] -> await connect -> add read to event loop
read = [await notify, await write, await disconnect]
It's possible for aux to be in the event loop more than once, that means that multiple tasks can be on await connect
and then after they all connect there will be multiple connections can be open at the same time.
I apologize, I minimized my code to share the example in this issue and accidentally took out too much code; the busy
flag was set to a value when creating the client poll task. I updated the above code.
Like I said, I should have simplified this example even more, the problem also occurs without running the asyncio task from the JKviewer.poll()
function.
Having said all this: I'm still sure any abuse or wrong API usage from userspace should result in the kernel/driver/firmware getting confused beyond repair, but that's another store.
Thanks,,
self.busy
will show the name of the current device but it can also be set multiple times without being None
. It can be set to a name when it is currently a name.
the problem also occurs without running the asyncio task from the JKviewer.poll() function.
Can you modify your code snippet to be the minimal example that shows the problem?
FYI, calling asyncio.create_task()
in the poll()
methods without keeping a handle to the returned task will allow the task to be garbage collected before the task completes. See https://docs.python.org/3.12/library/asyncio-task.html#asyncio.create_task
Polling with await asyncio.sleep(0.1)
also kind of defeats the purpose of asyncio. There are better alternatives like asyncio events, futures and queues depending on what you are trying to do.
FYI, calling
asyncio.create_task()
in thepoll()
methods without keeping a handle to the returned task will allow the task to be garbage collected before the task completes.
Right, I'll have to take care of that.
Polling with
await asyncio.sleep(0.1)
also kind of defeats the purpose of asyncio. There are better alternatives like asyncio events, futures and queues depending on what you are trying to do.
Sure, I'm aware of that - my example is just lousy.
Shall I close this issue and reopen if/when I reproduce with a simpler and more compact program?
Shall I close this issue and reopen if/when I reproduce with a simpler and more compact program?
Sounds good. So far, this sounds more like a hardware issue than a Bleak issue.
Is it a problem if multiple tasks await client.connect()
?
For example, event loop runs task1 which runs await client1.connect()
which yields to the event loop and then the event loop runs tasks2 which runs await client2.connect()
?
Is it a problem if multiple tasks await client.connect()?
Yes, it seems that is a reliable way to trigger this problem. My example code was messy though, so if I find the time to get this running again I'll come up with a more simple snippet.
Closed for now.
Should that work though?
Why doesn't it work? Because the backend can't handle multiple connection requests at the same time???
If that's the case can BleakClient
ensure only one connect is requested to the backend at a time?
How do backends handle when multiple processes call connect at the same time?
I'm not sure what causes the limitation, but the "two clients" examples jumps through hoops to make sure only one connect()
is running at a time:
https://github.com/hbldh/bleak/blob/develop/examples/two_devices.py#L40-L41
Why doesn't it work? Because the backend can't handle multiple connection requests at the same time???
It can be an OS limitation like BlueZ returning "operation already in progress" errors. Or it can be a hardware limitation like the issue here.
If that's the case can
BleakClient
ensure only one connect is requested to the backend at a time?
I would rather leave it up to the user in case they want a different behavior, like getting a busy error instead of just waiting a indefinite amount of time. If we changed it now, I think it would break a lot of people's code that depend on the current behavior.
How do backends handle multiple processes call connect at the same time?
They probably don't handle it well since it was never really designed to do that (since it often doesn't work at the OS level anyway).
Thanks for explaining and sorry if I missed the documentation on this.
like getting a busy error
Is that what happens? Why not handle a busy error instead of using the lock in the two_devices.py example?
The busy error is specific to the BlueZ backend. The lock works cross-platform - and avoids the error in the first place.
The busy error is specific to the BlueZ backend. The lock works cross-platform - and avoids the error in the first place.
It only avoids the error if another process doesn't use Bluetooth.
If we changed it now, I think it would break a lot of people's code that depend on the current behavior.
There can be a new class with the new behaviour and when you use the new class you opt in to the new behaviour.
python3-bleak
packageDescription
I have a simple python script that has the task to poll a large number of devices (50 to 100). I want to optimize the process by not serializing all connects + polls + disconnects, see below.
The result is that the bluetooth stack on my rpi crashes. Clients are no longer disconnecting and scanning never terminates.
kernel logs show:
Not able to power off/on as well:
Also tested with an external USB bluetooth dongle, same results.
What I Did
, the procedure I have now is:
This works pretty much ok but is rather slow as there is only one active client connection at a time.
I understand that doing multiple connects in parallel is no recommended (yes I have looked at the two-devices example), but having multiple connections established should be fine. This is what I changed my code to now, effectively this serializes the
connect()s
, but allows the polling and disconnect to run async:As far as I know, this should abide to all the rules:
I also tried to postpone the scanning until all the active clients have disconnecetd, but to no avail.
Minimal workable example is not easy since there is a large number of specific devices involved.
Logs
BLEAK_LOGGING=1
log attached (sorry for the newlines, this was copy/pasted from a scrollback buffer)debug-log.txt
Code
Below is the code as I run it now, albeit stripped a bit from error handling and the protocol details that are not relevant: