Strange interaction with multiple greenlets with the same parent and asyncio/coroutine/generator

[CaselIT]

I was experimenting with the example provided in the documentation and I noticed a strange behavior when using asyncio.
This is an example script:

import asyncio
import greenlet

def syncg():
    print("before g2")
    print("g2 result", syncg2.switch())
    print("after g2")

def g2sync():
    print("in g2")
    return 42

syncg1 = greenlet.greenlet(syncg)
syncg2 = greenlet.greenlet(g2sync)
print("sync version")
print("sync result", syncg1.switch())

async def asyncg():
    print("before g2")
    print("g2 result", asyncg2.switch())
    print("after g2")

def g2async():
    print("in g2")
    return 42

asyncg1 = greenlet.greenlet(asyncg)
asyncg2 = greenlet.greenlet(g2async)
print("asyncio version")
print("asyncio result", asyncio.run(asyncg1.switch()))

My understanding is that these two cases should be equal and print the lines "before g2" and "in g2" and return 42.
The async version resumes the execution of asyncg1 after asyncg2 exits instead.
This is the output:

sync version
before g2
in g2
sync result 42
asyncio version
before g2
in g2
g2 result 42
after g2
asyncio result None

python: 3.8.3
greenlet: 0.4.16

I tested on windows but the same behavior happen on linux

[CaselIT]

The same behavior is observed by using generators. The example below provided by @vytas7:

import greenlet

def gen_func1():
    print('entering generator')
    print('before g2')
    print('g2 result', g2.switch())
    print('after g2')
    yield 'Bye'

def func1():
    print('in g2')
    return 42

g1 = greenlet.greenlet(gen_func1)
g2 = greenlet.greenlet(func1)

gen = g1.switch()
next(gen)

yields

entering generator
before g2
in g2
g2 result 42
after g2

[vytas7]

FWIW, with the above example I actually wanted to illustrate that Greenlet was behaving as expected and documented.

But maybe documentation could be improved to discuss something in this vein, walking through each step and explaining what happens.

[CaselIT]

Indeed it appears that with asyncio/generator/coroutine the first greenlet switches to the constructor of the coroutine/generator and exits returning the generated coroutine/generator instance. When this is awaited/iterated over the main greenlet executes, leading to the documented behaviour.

It would be nice if an example of this kind could be documented similarly to this one

[snaury]

I'm not sure it's a good idea to mix greenlet and asyncio like that. The interaction is perfectly normal, when dying a greenlet will switch to its parent with whatever result it has. All greenlets in your example have main greenlet as parent, so when g2sync finishes main greenlet receives the result 42. In the asyncio example you return back to the run method, which concidentally is executing asyncg2.switch().

It is recommended that in async systems your greenlets have a well known and expected parent, which starts them and handles termination. For example if I remember correctly gevent uses a special hub greenlet as parent for all of its greenlets, so when greenlets are finished execution is naturally passed back to the event loop.

[CaselIT]

Thanks for the reply.
So if I understand correctly, your advice is to first create a greenlet and in it's run method execute async code?
Something along the lines of

async def asyncg():
    print("before g2")
    print("g2 result", asyncg2.switch())
    print("after g2")

def g2async():
    print("in g2")
    return 42

def execute():
    global asyncg1, asyncg2
    asyncg1 = greenlet.greenlet(asyncg)
    asyncg2 = greenlet.greenlet(g2async)
    print("asyncio version")
    print("asyncio result", asyncio.run(asyncg1.switch()))

parent = greenlet.greenlet(execute)
parent.switch()

[snaury]

No, that's not what I'm saying. Greenlet is a very low-level primitive, you shouldn't just switch to random greenlets without knowing how you get back. You may try using existing abstractions (gevent, eventlet, etc.) or build your own, switching outside of your framework's control is a bad idea.

In your example you create greenlets in one context, but switch to them from another, which feels weird. Your asyncg is switching into g2async, but you have no logic to get back. I would recommend using gevent.spawn instead of raw greenlets, and communicating via Event, AsyncResult and other primitives that you can wait for.

[CaselIT]

Thanks, I'll look into that.

Do you think it would be appropriate to mention in the documentation that using a generator or coroutine as the target function for a greenlet does not execute said function inside the greenlet? I can try to provide a PR to the documentation for it

[snaury]

Greenlet just calls whatever is passed. Generator functions return their generator when called, so there's nothing to clarify.

[CaselIT]

That was not immediately clear that the generator does not run inside the greenlet.
Anyway thanks for the clarification.

[zzzeek]

@snaury feel free to take a look at our current POC at https://gist.github.com/zzzeek/769b684d4fc8dfec9d4ebc6e4bb93076 . the original one I came up with, which had two greenlets, is at https://gist.github.com/zzzeek/4e89ce6226826e7a8df13e1b573ad354 .

this recipe is basically going to be used by SQLAlchemy and probably a lot of other projects to bridge the gap between asyncio on the front and back and libraries that internally use synchronous calling styles.

[snaury]

@zzzeek I think I understand what you're trying to do, you're trying to have a way to switch back to asyncio from an arbitrarily nested "sync" code running in a greenlet, but I'm not sure why? Your switching method is not generic, it only works with your specially created greenlets, so a user must choose to use your spawn function. It means user needs to rewrite parts of their code, why not just use async def all the way?

Is it like a web-server where arbitrary sync handlers are expected to use await_ deep in their call stack, and would such a web-server use greenlet_spawn to like make a separate thread of execution that is potentially deep and blocking?

In that case I would recommend making run_greenlet_target a subclass of greenlet with some state instead of a free function. Also, don't use parent (it's possible to overwrite that field, not that many use it probably) and remember current "driver" greenlet (getcurrent from inside run_greenlet) instead. It would make checking whether await_ is in the correct context easier (with a simple isinstance).

The next thing that I would do is adding more checks, i.e. whether the switch back was expected or not. That would mean remembering placing some cookie in the greenlet state and checking if you returned with that cookie or for some other reason.

It is also possible to get rid of result_future too. You already have a run_greenlet async driver, you just need to detect whether the switch result was final (i.e. your gl is dead) or temporary (because of a switch). The final result may just be returned as is, so it would become something like result = await run_greenlet(); return result. Coincidentally you are already doing that in case your greenlet terminates due to exception, it's possible to use it for normal returns too. That probably means run_greenlet becomes an unnecessary wrapper, which may be inlined inside greenlet_spawn directly. And run_greenlet_target body becomes just return fn(*args), which you would pass down to greenlet constructor.

Hope that helps.

[zzzeek]

@zzzeek I think I understand what you're trying to do, you're trying to have a way to switch back to asyncio from an arbitrarily nested "sync" code running in a greenlet, but I'm not sure why? Your switching method is not generic, it only works with your specially created greenlets, so a user must choose to use your spawn function. It means user needs to rewrite parts of their code, why not just use async def all the way?

the primary goal is not about giving greenlets to end users. it's about using greenlets inside of a library networking-oriented library that wishes to present an asynchronous interface that goes down to an asynchronous network service. Specifically database absraction layers. Here is the use of await_() in SQLAlchemy: https://gerrit.sqlalchemy.org/plugins/gitiles/sqlalchemy/sqlalchemy/+/refs/changes/71/2071/16/lib/sqlalchemy/dialects/postgresql/asyncpg.py#269

There is a secondary, more controversial goal that SQLAlchemy might provide the "greenlet_spawn" function to end users as well. They will not have to call await_() either, as they are calling into SQLAlchemy, which then calls into the above linked database driver that calls await. I get that nobody in the asyncio camp is happy with that idea but it seems to me very similar to what people do with gevent all the time.

So there are two usage patterns both supported by the recipe.

Here's the main one, async SQLAlchemy: https://gerrit.sqlalchemy.org/plugins/gitiles/sqlalchemy/sqlalchemy/+/refs/changes/71/2071/16/examples/asyncio/basic.py

Here's the more controvrsial one, an application that uses async SQLAlchemy can opt to have some functions wtihin a greenlet: https://gerrit.sqlalchemy.org/plugins/gitiles/sqlalchemy/sqlalchemy/+/refs/changes/71/2071/16/examples/asyncio/greenlet_orm.py

Both programming patterns are in fact highly desired. The second one is roughly like how many people use SQLAlchemy and other database abstraction libraries with gevent. however my version does not require monkeypatching of a synchronous library, we can use asyncpg directly.

Is it like a web-server where arbitrary sync handlers are expected to use await_ deep in their call stack, and would such a web-server use greenlet_spawn to like make a separate thread of execution that is potentially deep and blocking?

yes it can work that way also, some folks are trying to get this to work for Flask right now, for example.

In that case I would recommend making run_greenlet_target a subclass of greenlet with some state instead of a free function. Also, don't use parent (it's possible to overwrite that field, not that many use it probably) and remember current "driver" greenlet (getcurrent from inside run_greenlet) instead. It would make checking whether await_ is in the correct context easier (with a simple isinstance).

My original version at https://gist.github.com/zzzeek/4e89ce6226826e7a8df13e1b573ad354 doesn't use .parent, it uses a contextvar to figure out where it's going. I'll try your subclass idea and see if i can get that working thanks! usually subclassing is not something we do lightly without permission from the framework authors but if that's a greenlet supported case then OK.

The next thing that I would do is adding more checks, i.e. whether the switch back was expected or not. That would mean remembering placing some cookie in the greenlet state and checking if you returned with that cookie or for some other reason.

yes the contextvar tries to do that but maybe the subclass approach makes it easier.

It is also possible to get rid of result_future too. You already have a run_greenlet async driver, you just need to detect whether the switch result was final (i.e. your gl is dead) or temporary (because of a switch). The final result may just be returned as is, so it would become something like result = await run_greenlet(); return result.

also a great idea! yeah i get that, OK. that might iron out the small performance difference this seems to have over straight await.

Coincidentally you are already doing that in case your greenlet terminates due to exception, it's possible to use it for normal returns too. That probably means run_greenlet becomes an unnecessary wrapper, which may be inlined inside greenlet_spawn directly. And run_greenlet_target body becomes just return fn(*args), which you would pass down to greenlet constructor.

OK! basically last friday was the first time I ever tried to look at "greenlet" directly and it made a pretty big splash with a lot of people that this was even possible in as short of an example as I had.

Hope that helps.

yeah great ideas!