Hey Phil!

I know my views are different than many on this topic, but the main (only?) reason I would use an asynchronous server over a synchronous one is to achieve much higher scaling. This solution obviously does not address this problem, so this should be noted. I think the note about the performance is warranted, but just a partial aspect, the scaling limitations should be noted as well.

A second thought is that it would be nicer if multiple async view functions could run concurrently in the asyncio thread, all under the same loop. I believe your implementation would allow only one async function to run at any given time. It seems there wouldn't be any problem in using a shared loop to run all of them concurrently, and that would eliminate some of the performance penalties in using this solution, I think.

Hi Miguel!

I agree with you on both points (except that I think this does allow multiple async functions to run at once if the server is threaded or green threaded - each async function would get its own thread). With the latter point, I'd rather not explore how to implement running all functions under the same thread without a feeling that this is the right approach for Flask.

Phil, I may be missing something. You are starting a thread pool of size 1 hardcoded, which means that you will have only one asyncio thread per Flask process. Even if you used a threaded server, the bottleneck is the single asyncio thread. You could make that size of 1 configurable, and then you can have some control over how many asyncio view functions can run concurrently, but that seems backwards to me. I think running all of them in a single loop is what makes most sense. I agree with you on that there is no point in going through the effort until we decide to go forward with a solution of this type.

I've had individual discussions with @mitsuhiko, @andrewgodwin, and @pgjones that lead to this implementation as a possible first step, despite the limitations you point out. The first goal is to enable @route() async def at all. Later improvements could build on this.

Please continue to discuss, I wanted to add some context for why this implementation was submitted.

@pgjones if it's helpful, I don't mind an optional dependency on asgiref, as they have some nice async/sync helpers already.

I suggest we create a v2 branch and putting async into v2. And in v2, we don't support Python 2.7 anymore.

I'd prefer to avoid a v2 branch, and wait till next year and the end of Py2 before merging this. (Edit: Forget to say why). As I don't think it is worth maintaining a v2 branch as it couldn't be released.

I've looked into asgiref, I'm not sure it is a good fit here - will take another look though, thanks.

@pgjones master is Python 3 only now, this can be rebased.

@davidism I think this is good to review and potentially merge.

I've updated, and think it is good to merge.

Just to note I see this is the start of async support in Flask rather than a complete solution - there are a number of unanswered questions e.g. what about views that return async iterators?

AnyIO is better choice than asgiref?

Saw @miguelgrinberg tweet about using an async SQLAlchemy demo: https://twitter.com/miguelgrinberg/status/1279894131976921088, might be relevant to consider with this. Here's the greenlet to async gist: https://gist.github.com/zzzeek/6287e28054d3baddc07fa21a7227904e

@davidism So it's still somewhat early to call victory on this, but if you want some details on what I have done...

What Mike Bayer's gist made me realize is that you can do greenlet context switches within an asyncio task, and this allows us to interrupt standard functions and send control back to the asyncio loop. To test this out I added a custom hub class to eventlet that does all the waiting using asyncio primitives such as asyncio.add_reader, add_writer, etc.

Since Flask runs great with greenlets, I can now run Flask on top of eventlet, which runs on top of asyncio! Here is some of the crazy things I've tested:

• await for an async function in a normal Flask view function (without blocking, obviously):

@app.route('/foo')
def foo():
    await_(asyncio.sleep(1))
    return 'Hello!'

The await_ helper function uses asyncio.create_task() to launch the passed coroutine as a normal asyncio function, and then uses a greenlet based event to wait for it to complete w/o blocking.

• use an async function as a Flask view function by decorating it with the same await_ helper:

@app.route('/foo')
@await_
async def foo():
    await asyncio.sleep(1)
    return 'Hello!'

• await a non-blocking standard function inside an async function. Here is requests.get() with eventlet monkey-patching:

@app.route('/baz')
@await_
async def baz():
    rv = await make_awaitable(requests.get, 'https://google.com')
    print(rv)
    return 'Hello!'

The make_awaitable() helper function starts a greenlet on the requested function and waits for it to complete using a asyncio.Future.

None of this is Flask specific, actually. In fact I haven't had to hack on any official packages, this is all running on official Flask, greenlet and eventlet packages.

What I love about this solution is that all of this works on a single OS thread, without executor tricks. It's truly an asyncio application that just has some "under the table" context switches done via greenlet.switch(). And the eventlet monkey-patching allows blocking functions in the Python standard library to run on top of asyncio and become awaitables.

I hope I will have something that people can test and poke holes at soon.

@miguelgrinberg et al. quoting @oremanj in https://twitter.com/oremanj/status/1279994426538905600

I packaged this a few months ago as https://github.com/oremanj/greenback — it is indeed a useful tool to have in one’s toolbox!

As I understand the greenlet based solutions they work by switching back to a (prime) coroutine in order to await i.e. every await_ switches to the prime, awaits normally and then switches back. This then requires an event loop to run and await the prime coroutine. Running the event loop is the problem that this PR solves using a thread.

It isn't clear to me how the greenlet solutions help, as Flask has no event loop available to it and running an event loop in a thread is equivalent to this PR.

@miguelgrinberg would I be correct in thinking that the Eventlet hub acts as an asyncio event loop substitute? I'm thinking it allows the awaiting of coroutines as if the coroutine was awaited in an asyncio event loop? Actually reading further, I think you are running Flask within an asyncio loop?

would I be correct in thinking that the Eventlet hub acts as an asyncio event loop substitute

Not really. The eventlet hub is an asyncio task, running in a 100% asyncio application. It's a single OS thread for eventlet's hub with all of its greenlets plus any normal asyncio stuff.

Actually reading further, I think you are running Flask within an asyncio loop?

Right. So Flask runs as a greenlet, either under Eventlet's WSGI server, or with the monkey-patched Werzeug dev server. So each request is started on a greenlet. If you call this await_ helper function then there is a switch to the eventlet hub's greenlet, which is an async function that has full access to await on things. And if you issue any I/O using eventlet functions, those are sent to the hub, which calls asyncio.add_reader or asyncio.add_writer to wait on the file descriptors using asyncio support.

@pgjones I'm not 100% sure, but I think there's an issue with contexts. Are mutations to request, session, and g visible for the entire request? For example, a before_request function sets something that a decorator on the view function looks at, such as Flask-Login. Flask-Login also has its own context local, current_user. Each async function copies the request context and runs in a separate thread. Not sure how that will change (for better or worse) with ContextVar in pallets/werkzeug#1778.

I think mutation would be fine, isn't it fine when you use copy_current_request_context? I believe the contexts are copied, but the request, session, app, and g, objects referenced by the contexts are the same. (Are you thinking about the copy or something else?)

I don't think the Flask-Login context will work, however the extension could update the helper to copy the context as well.

I don't think ContextVars affect either point here.

Note that @davidism and I have discussed that this implementation must support extensions overriding the Flask.ensure_sync method to change the usage throughout. This turns out to be difficult given the Scaffold changes, and the best solution we've found so far results in the slightly unpleasant empty Blueprint.ensure_sync method.

Updated docs are look good to me.

🎉