In my brief evaluation of this substantial info. It looks to me like:
Generators aren't quite ready to be the soln for async concurrency. But are looking promising for future.
Having said that Diesal web is a legitimate solution which exists and works this way now.
The other approach appears to be Greenlet based - and is also working and performing well.

Of course moost of these discussions center around webservers (as they want concurrent socket based ops right now) rather than the focus on async processes which we would like in an embedded approach.
I need to read more...

http://diesel.io/
https://pypi.python.org/pypi/greenlet

I saw Protothreads and the description sounded good, but it may be too simplistic to get uPy functions running asynchronously.

http://dunkels.com/adam/pt/

@dpgeorge: Well, protothreads are inferior analogue of python generators (which are both kinds of coroutines). We don't need them in uPy, they're needed when you have 1K of flash and 128b of RAM ;-). What you already implemented of generators is more advanced and flexible than protothreads.

Btw, I thought you had generators destined as concurrency model yourself, because I'd personally implemented generator support the last thing otherwise ;-).

FWIW, async generators have been picking up momentum in recent years in more mature mainstream frameworks - for example the relatively recent introduction of it into the core c# language, which is now the recommended approach on that platform.

My point being that developers are more accepting of the approach today than they would have been several years ago.

Personally, I like them.

Hah, well, I just wanted to get as Python-conformant as I could, and generators didn't need much extra work, so they are there.

I'll have to learn more about how to use them as async concurrency.

Do you think it's enough to have concurrency at the Python high-level, and not at the C level? It's much easier at the Python level (since it's basically done).

To get it working, is there more to implement in the core of uPy, or is it just a pure Python library that needs to be ported?

It's probably worth getting terminology straight, because there's duality between synchronous/asynchronous stuff in multitasking framework. With (typical implementation of) cooperative multitasking we want to handle async events/processes with sync event loop. And with preemptive multitasking, we want to have synchronous processes scheduled and running asynchronously.

So, the talk here about cooperative multitasking model, I updated the title. This can be implemented in pure Python. I don't even raise question of preemptive multitasking. First of all, I don't think that's useful for MCU usage. And that surely would require RTOS, enough memory for thread stacks, etc. Thread-based multitasking would be more useful for unix port, even though best practice would be to implement thread pool to adapt blocking sync services into cooperative async ones. But even that would require either pseudo-threadsafety with locks (oh no, we had enough of GIL!) or doing true "lockless" threadsafety by supporting multiple VMs (Squirrel does that, each and every API function takes VM pointer, how do you like that?)

To get it working, is there more to implement in the core of uPy, or is it just a pure Python library that needs to be ported?

So, I submitted this informal ticket essentially as a prelude to #243. Trivial "embedded" coop concurrency trivially doable with py2.3 generators:

queue = []
def task1(param):
    while 1:
        queue.append(param)
        yield
def task2():
    while 1:
        while queue:
            print(queue.pop(0))
        yield
tasks = [task1(10), task1(20), task2()]
while 1: for t in tasks: next(t)

To add seamless async i/o (which looks like "system service", though actually implemented by the similar coroutine as any other task), it takes 2.5 .send() method, implemented by me recently. But to make it real-world usable, exception handling needs to be implemented, which is concern of #243.

I'll have to learn more about how to use them as async concurrency.

I recommend David Beazley's tutorial (# 4 above), it in particular clearly addresses @Neon22's concern that "they center around webservers rather than the focus on async processes which we would like in an embedded approach." - no, there's no difference, they center around arbitrary async events/processes and there's elegant way to plug anything and everything.

Ok, Python 3.4 was released, featuring asyncio module: http://docs.python.org/3.4/library/asyncio.html . Googling around, it's getting its critical acclaim. So, it's no longer a question, it's the fact: cooperative concurrency model of choice for Python is coroutines via generators.

But asyncio is based on "yield from" construct, which itself appeared only in py3.3. uPy doesn't have it implemented so far. So, what is "yield from" and why it was selected as the base for async implementation? Explanation directly from Guido van Rossum (Python author): https://groups.google.com/forum/#!msg/python-tulip/bmphRrryuFk/aB45sEJUomYJ

Nice read from Guido about yield from. Now we just need to implement it... :)

Yeah, opened #366 for that, because it's not clear at all how it should be implemented ;-).

Current state:

1. There's a branch for asyncio-like API in: https://github.com/micropython/micropython-lib/tree/asyncio
2. It's "asyncio-like" because I found that asyncio design decisions don't fit well with those of MicroPython, uPy's primary goal is to stay lean and efficient while asyncio's goal is to provide interoperatibility framework for existing async libraries, more info: https://groups.google.com/forum/#!topic/python-tulip/zfMQIUcIR-0
3. There's now a thread on forum to continue discussion: http://forum.micropython.org/viewtopic.php?f=3&t=85

Closing this ticket thus.