Environment: cooperative RTOS in C and micropython virtual machine is one of the tasks.
To make the VM not block the other RTOS tasks, I insert RTOS_sleep()
in vm.c:DISPATCH()
so that after every bytecode is executed, the VM relinquishes control to the next RTOS task.
I created a uPy interface to asynchronously obtain data from a physical data bus - could be CAN, SPI, ethernet - using producer-consumer design pattern.
Usage in uPy:
can_q = CANbus.queue()
message = can_q.get()
The implementation in C is such that can_q.get()
does NOT block the RTOS: it polls a C-queue and if message is not received, it calls RTOS_sleep()
to give another task the chance to fill the queue. Things are synchronized because the C-queue is only updated by another RTOS task and RTOS tasks only switch when RTOS_sleep()
is called i.e. cooperative
The C-implementation is basically:
// gives chance for c-queue to be filled by other RTOS task
while(c_queue_empty() == true) RTOS_sleep();
return c_queue_get_message();
Although the Python statement can_q.get()
does not block the RTOS, it does block the uPy script.
I'd like to rewrite it so I can use it with async def
i.e. coroutine and have it not block the uPy script.
Not sure of the syntax but something like this:
can_q = CANbus.queue()
message = await can_q.get()
QUESTION
How do I write a C-function so I can await
on it?
I would prefer a CPython and micropython answer but I would accept a CPython-only answer.
Note: this answer covers CPython and the asyncio framework. The concepts, however, should apply to other Python implementations as well as other async frameworks.
The simplest way to write a C function whose result can be awaited is by having it return an already made awaitable object, such as an
asyncio.Future
. Before returning theFuture
, the code must arrange for the future's result to be set by some asynchronous mechanism. All of these coroutine-based approaches assume that your program is running under some event loop that knows how to schedule the coroutines.But returning a future isn't always enough - maybe we'd like to define an object with an arbitrary number of suspension points. Returning a future suspends only once (if the returned future is not complete), resumes once the future is completed, and that's it. An awaitable object equivalent to an
async def
that contains more than oneawait
cannot be implemented by returning a future, it has to implement a protocol that coroutines normally implement. This is somewhat like an iterator implementing a custom__next__
and be used instead of a generator.Defining a custom awaitable
To define our own awaitable type, we can turn to PEP 492, which specifies exactly which objects can be passed to
await
. Other than Python functions defined withasync def
, user-defined types can make objects awaitable by defining the__await__
special method, which Python/C maps to thetp_as_async.am_await
part of thePyTypeObject
struct.What this means is that in Python/C, you must do the following:
tp_as_async
field of your extension type.am_await
member point to a C function that accepts an instance of your type and returns an instance of another extension type that implements the iterator protocol, i.e. definestp_iter
(trivially defined asPyIter_Self
) andtp_iternext
.tp_iternext
must advance the coroutine's state machine. Each non-exceptional return fromtp_iternext
corresponds to a suspension, and the finalStopIteration
exception signifies the final return from the coroutine. The return value is stored in thevalue
property ofStopIteration
.For the coroutine to be useful, it must also be able to communicate with the event loop that drives it, so that it can specify when it is to be resumed after it has suspended. Most of coroutines defined by asyncio expect to be running under the asyncio event loop, and internally use
asyncio.get_event_loop()
(and/or accept an explicitloop
argument) to obtain its services.Example coroutine
To illustrate what the Python/C code needs to implement, let's consider simple coroutine expressed as a Python
async def
, such as this equivalent ofasyncio.sleep()
:my_sleep
creates aFuture
, arranges for it to complete (its result to become set) in n seconds, and suspends itself until the future completes. The last part usesawait
, whereawait x
means "allowx
to decide whether we will now suspend or keep executing". An incomplete future always decides to suspend, and the asyncioTask
coroutine driver special-cases yielded futures to suspend them indefinitely and connects their completion to resuming the task. Suspension mechanisms of other event loops (curio etc) can differ in details, but the underlying idea is the same:await
is an optional suspension of execution.__await__()
that returns a generatorTo translate this to C, we have to get rid of the magic
async def
function definition, as well as of theawait
suspension point. Removing theasync def
is fairly simple: the equivalent ordinary function simply needs to return an object that implements__await__
:The
__await__
method of the_MySleep
object returned bymy_sleep()
will be automatically called by theawait
operator to convert an awaitable object (anything passed toawait
) to an iterator. This iterator will be used to ask the awaited object whether it chooses to suspend or to provide a value. This is much like how thefor o in x
statement callsx.__iter__()
to convert the iterablex
to a concrete iterator.When the returned iterator chooses to suspend, it simply needs to produce a value. The meaning of the value, if any, will be interpreted by the coroutine driver, typically part of an event loop. When the iterator chooses to stop executing and return from
await
, it needs to stop iterating. Using a generator as a convenience iterator implementation,_MySleepIter
would look like this:As
await x
maps toyield from x.__await__()
, our generator must exhaust the iterator returned byfuture.__await__()
. The iterator returned byFuture.__await__
will yield if the future is incomplete, and return the future's result (which we here ignore, butyield from
actually provides) otherwise.__await__()
that returns a custom iteratorThe final obstacle for a C implementation of
my_sleep
in C is the use of generator for_MySleepIter
. Fortunately, any generator can be translated to a stateful iterator whose__next__
executes the piece of code up to the next await or return.__next__
implements a state machine version of the generator code, whereyield
is expressed by returning a value, andreturn
by raisingStopIteration
. For example:Translation to C
The above is quite some typing, but it works, and only uses constructs that can be defined with native Python/C functions.
Actually translating the two classes to C quite straightforward, but beyond the scope of this answer.