[Bug] Hub can get stuck while broadcasting

[JJHackimoto]

Describe the bug
Block Coding: When using Broadcast in two or more tasks running simultaneously, an error will be thrown and the program will terminate. Error below:

"OSError: This resource cannot be used in two tasks at once."

Expected behavior
I expected the block coding to give me an error or prevent me from building the program this way before running the program. This is especially true since block coders may not be that experienced in coding, and may not understand the error thrown in the console. The error won't be seen if running the program off the hub without a bluetooth connection either.

I could also expect this to just work since I personally can't see the reason for this not working. It currently feels unintuitive that the only way to use Broadcasting is to have a loop that constantly sends out the chosen values instead of just sending an update when the values have actually changed (for example when just sending out Booleans once in a while).

[laurensvalk]

Thanks for raising this. This is the expected behavior (as in, not a bug), but I can see this being not ideal. We could perhaps improve this with documentation and a clear example.

I could also expect this to just work since I personally can't see the reason for this not working.

A fair analogy is screaming two different things from the same rooftop at the same time 😄 So even if we made the error go away, this probably isn't going to work as you'd like. The receiver wouldn't be guaranteed to receive both.

To send two values, it's better to send them together in a list. So if your code wants to send variables A and B from two different tasks, you could make a another task that just broadcasts a new list of A & B whenever either of them changes.

Generally in Pybricks, we try to raise the error when there is one, instead of not telling you and leaving you confused why something isn't working.

I expected the block coding to give me an error or prevent me from building the program this way before running the program.

We couldn't know in advance how the program might run. It's perfectly fine if two tasks both use broadcasting, just not at the same time.

[JJHackimoto]

I see, thanks for the clarification. Now, I'm not sure how this could work, but wouldn't it be possible to make broadcasting always happen asynchronously when using block coding? This way, it would never occur at the same time no matter where in the program the call is used.

Feel free to close this issue if you decide that no changes are needed for this :)

[laurensvalk]

That way, you'd still 'drown' one message in the other, so overall responsiveness is likely not as good compared to intentionally combining the messages as needed depending on your application.

[laurensvalk]

Let's keep the issue open since it's definitely a good question. We'll want to document this clearly and explain why =)

[JJHackimoto]

In addition to this, is it true that broadcasting and unpacking cannot be done at the same time as well?
I've had a few issues with hubs freezing where the blue light continue to fade as normal but hub is stuck and only thing to do is to power it down with a long press. Short press won't work.
After moving all Bluetooth communication blocks to a single task that runs repeatedly, the issue seem to have gone away.

[laurensvalk]

That should be allowed. If you find a reproducible small program we can test, that would be very useful!

[laurensvalk]

I did find #1454. Maybe you were seeing this too?

[JJHackimoto]

That one is interesting. Did your hub continue to fade blue during and after the "crash"?

I've yet to have this happen while connected to a computer, and it's really inconsistent in when it happens, sometimes after a minute, and sometimes after 10. Other times it doesn't happen at all during the time I'm testing with my program. I'm still using three hubs communicating with each other and this far, two of them have randomly "crashed", one more often than the other. The third hub has been fine all the time. The difference between how they handle communication is that the good hub has been doing it in a loop in a separate task. The other two have only been unpacking in a loop in a separate task, while broadcasting from the main program whenever needed. I've since moved it all to that separate loop and it seems to have been fine since then on all three hubs.

I'll see if I can reproduce it with a small program.

[laurensvalk]

That one is interesting. Did your hub continue to fade blue during and after the "crash"?

No, so maybe you're seeing something different.

I'll see if I can reproduce it with a small program.

Thank you!