[Feature] asyncio.Event (or other way to let one coroutine block on another)

[abliss]

Is your feature request related to a problem? Please describe.
When using multitasking, I would like to have one coroutine block to await something happening in another coroutine. Currently I think I have to setup a sleeping-wait loop for this, which is unsatisfactory because lower sleep amounts waste resources and higher sleep amounts make the latency worse.
I see that uselect offers polling but apparently only for FileIO streams, so it's not clear if I can use this to do what I want.

Describe the solution you'd like
I'd like to be able to instantiate an asyncio.Event object as described in https://docs.micropython.org/en/latest/library/asyncio.html#class-event so that one coroutine can event.clear(); await event.wait() and a second coroutine can run event.set() when it's ready to unblock the first one.
Describe alternatives you've considered
I tried running the above code on the spike prime hub but it said no module named 'asyncio'.

[dlech]

Since Pybricks is running on a microcontroller, wasting CPU cycles doesn't really matter. There isn't a low power mode or anything, so "efficient" waits make no measurable difference.

In Pybricks (except for v2.x on ev3dev because it is Linux), it is perfectly reasonable to do something like:

from pybricks.tools import wait


class Event:
    def __init__(self):
        self._condition = False

    def set(self):
        self._condition = True

    def clear(self):
        self._condition = False

    async def wait():
        while not self._condition:
            await wait(0)

[abliss]

Thanks. That's the workaround I'm using now. But....

1. What if the other task is something that is constrained by cpu-time (but has yield points in it)? Won't it finish more slowly if the microcontroller has to keep switching to the Event.wait loop at every yield point?
2. Or what if the other task is something like a PID loop that is more accurate when it has finer-grained samples? Won't switching to the wait-loop and back necessarily take up some time between samples, making them coarser and making the coroutine less accurate?
3. Are we guaranteed that await wait(0) will always cause the scheduler to switch back to the other coroutine, or is there a risk this could starve it out?
4. What if I want to have 9 coroutines all blocked on the 1 coroutine that is doing some work? Won't the cpu have to switch to all 9 wait-loops at each yield point? This doesn't seem like it scales very well.

[dlech]

1. What if the other task is something that is constrained by cpu-time (but has yield points in it)?

With robotics, we tend to not be CPU constrained since we are usually waiting on sensors or motors to change. But if you have a real-world use case that seems to be affected like this, we would be glad to look into it.

2. Or what if the other task is something like a PID loop that is more accurate when it has finer-grained samples?

PID loops tend to be on the order of 10 milliseconds, so will have a delay in them much larger than the 10s of microseconds that it takes to check all other tasks. We do have an open issue on how we could have a timer with resolution higher than 1 ms, but it has been low priority since there aren't many use cases that are actually that sensitive. So again, if you have a real-world use case where this would make a difference, we would love to hear about it.

3. Are we guaranteed that await wait(0) will always cause the scheduler to switch back to the other coroutine

Yes, this was an intentional design decision.

4. Won't the cpu have to switch to all 9 wait-loops at each yield point?

Yes, but the CPU has nothing better to do anyway. Sure, it wouldn't scale well to 100s of tasks, but it would be quite unusual to have more than 10.

[abliss]

Sounds great, thanks! I will stick with the sleep-loop for now and will report back if it doesn't seem to fit the bill.