Event and Queue classes that support select and poll

[nickovs]

When implementing event-driven control code that needs to deal with events from interrupt handlers, IO stream and other threads, there is currently no efficient, low latency way for foreground code to watch for both the availability of stream data and events from background sources. The select module provides the select function and Poll class that can efficiently idle waiting for stream events, but to also watch other sorts of events the foreground code needs to periodically check. This can either poll rapidly, which doesn't make efficient use of CPU idling functions, or it can poll slowly, which leads to high latency. It would be great to be able to get the best of both worlds.

I propose that there be new Event and Queue classes that can be used along side sockets and IO stream in select calls and Poll objects. These would be explicitly safe to call from both hard interrupt contexts and alternate threads on platforms that support them, and would allow a single call to wait for any sort of event.

The general semantics for an Event would be similar to threading.Event class in CPython, with the addition that when it is provided to the select function or Poll class it would show as readable when the event is set and writable when the event is clear. A Queue would have the conventional put and get calls and would be readable when not empty and writable when not full. Queues would need to be fixed length in order to be used from hard interrupt handlers.

It's worth noting that there is an existing Event class in asyncio module that works for async code. The Python async model has its merits but many people find async code hard to debug and in my experience it's prone to stalling on MicroPython, so having a good alternative for synchronous programming would be valuable.

The implementation of these classes appears to be pretty simple. One open question is if these should be in a new module or if they should go into the existing select module.

Suggestions and comments welcomed.

[peterhinch]

async code ... prone to stalling on MicroPython

This claim is surprising (to me). Stalling is usually a result of calling a blocking function in an asynchronous task - a basic coding error.

You might be interested in this threadsafe queue - intended for interfacing asyncio code to hard ISR or threaded code.

[nickovs]

@peterhinch Firstly, thank you for building nano-gui; it's immensely useful!

This claim is surprising (to me). Stalling is usually a result of calling a blocking function in an asynchronous task - a basic coding error.

I've run into this problem multiple times, and in all cases I'm only calling code that either can't block at all or is awaiting functions in the asyncio module. I write a great deal of async code in CPython and have been doing so since the early days of PEP 492, so I'm aware of the common pitfalls. Generally I find that on Micropython some asyncio tasks can get starved of time and that renders their part of the code unresponsive. It's on my to do list to put together a test cases that is both small and reliably stalls.

Notwithstanding my confidence in my own code, you are correct that it is generally easy for coding errors to cause async code to stall. This supports my point that many people find debugging async code difficult, and it's even harder on Micropython where we don't have access to an IDE with breakpoints and an interactive debugger.

In many cases an event-based programming model is more appropriate than async code, especially when you have some core functionality that needs to respond to multiple stimuli from different sources and needs to keep state about the order in which those inputs arrived. As such, I think that there's still value in selectable/pollable events and queues for people whose code is better suited to a select/poll model.

It's also worth noting that the guts of Micropython's asyncio.IOQueue end up using select.Poll, so if pollable events and queues existed then they would be usable with the asyncio library as well as in synchronous polling code.

[peterhinch]

It's on my to do list to put together a test cases that is both small and reliably stalls.

I would very much like to see this as it's not my experience.

[shariltumin]

I am very interested in having a system similar to Socket Option 20.

s.setsockopt(socket.SOL_SOCKET, 20, handler)

Being able to register callbacks for any kind of user-defined event can be very useful.

I am very interested to see how you implement your event loop if you have any work in progress.