Trio support.

Via https://gitter.im/python-trio/general?at=5e2fe9b940da694c5edc8d70

It’d be nice to have Starlette support both Trio and Asyncio.

Currently it’s an asyncio-only framework, but there’s actually not many places where we’re tied to asyncio, with the exception of a bunch of “if this callable is a plain function then call into with with run_in_threadpool, otherwise await it.”.

I think the other places are:

• The WSGI middleware (optional). Currently has an asyncio-based implementation.
• The BaseHTTPMiddleware class (optional), that provides a request/response middleware interface to develop against, rather than directly writing against ASGI. Again, currently has an asyncio-based implemention.
• One weird part of the request model, .is_disconnected - that I think is structured as an anti-pattern and probably needs rethinking.
• The graphene-based GraphQL async executor, which probably ought to come out of the core package anyways.
• The existing TestClient, which we oughta replace with httpx now anyways, which does have trio+asyncio.

Short: Tweaking our run_in_threadpool function to use sniffio and then either call trio’s threadpooling or asyncio’s threadpooling would be sufficient as a starting point to start using Starlette with Trio.

[gdhameeja]

I’m taking this up.

[pquentin]

For what it’s worth, here’s an example of Uvicorn + Starlette + FastAPI running with trio-asyncio: https://github.com/python-trio/trio-asyncio/issues/84