# `tornado.platform.asyncio` — Bridge between `asyncio` and Tornado

Bridges between the `asyncio` module and Tornado IOLoop.

Added in version 3.2.

This module integrates Tornado with the `asyncio` module introduced in Python 3.4. This makes it possible to combine the two libraries on the same event loop.

Deprecated since version 5.0: While the code in this module is still used, it is now enabled automatically when `asyncio` is available, so applications should no longer need to refer to this module directly.

Note

Tornado is designed to use a selector-based event loop. On Windows, where a proactor-based event loop has been the default since Python 3.8, a selector event loop is emulated by running `select` on a separate thread. Configuring `asyncio` to use a selector event loop may improve performance of Tornado (but may reduce performance of other `asyncio`-based libraries in the same process).

class tornado.platform.asyncio.AsyncIOMainLoop(*args: Any, **kwargs: Any)

  `AsyncIOMainLoop` creates an `IOLoop` that corresponds to the current `asyncio` event loop (i.e. the one returned by `asyncio.get_event_loop()`).

  Deprecated since version 5.0: Now used automatically when appropriate; it is no longer necessary to refer to this class directly.

  Changed in version 5.0: Closing an `AsyncIOMainLoop` now closes the underlying asyncio loop.

class tornado.platform.asyncio.AsyncIOLoop(*args: Any, **kwargs: Any)

  `AsyncIOLoop` is an `IOLoop` that runs on an `asyncio` event loop. This class follows the usual Tornado semantics for creating new `IOLoops`; these loops are not necessarily related to the `asyncio` default event loop.

  Each `AsyncIOLoop` creates a new `asyncio.EventLoop`; this object can be accessed with the `asyncio_loop` attribute.

  Changed in version 6.2: Support explicit `asyncio_loop` argument for specifying the asyncio loop to attach to, rather than always creating a new one with the default policy.

  Changed in version 5.0: When an `AsyncIOLoop` becomes the current `IOLoop`, it also sets the current `asyncio` event loop.

  Deprecated since version 5.0: Now used automatically when appropriate; it is no longer necessary to refer to this class directly.

tornado.platform.asyncio.to_tornado_future(asyncio_future: Future) → Future

  Convert an `asyncio.Future` to a `tornado.concurrent.Future`.

  Added in version 4.1.

  Deprecated since version 5.0: Tornado `Futures` have been merged with `asyncio.Future`, so this method is now a no-op.

tornado.platform.asyncio.to_asyncio_future(tornado_future: Future) → Future

  Convert a Tornado yieldable object to an `asyncio.Future`.

  Added in version 4.1.

  Changed in version 4.3: Now accepts any yieldable object, not just `tornado.concurrent.Future`.

  Deprecated since version 5.0: Tornado `Futures` have been merged with `asyncio.Future`, so this method is now equivalent to `tornado.gen.convert_yielded`.

class tornado.platform.asyncio.AnyThreadEventLoopPolicy

  Event loop policy that allows loop creation on any thread.

  The default `asyncio` event loop policy only automatically creates event loops in the main threads. Other threads must create event loops explicitly or `asyncio.get_event_loop` (and therefore `IOLoop.current`) will fail. Installing this policy allows event loops to be created automatically on any thread, matching the behavior of Tornado versions prior to 5.0 (or 5.0 on Python 2).

  Usage:

      asyncio.set_event_loop_policy(AnyThreadEventLoopPolicy())

  Added in version 5.0.

  Deprecated since version 6.2: `AnyThreadEventLoopPolicy` affects the implicit creation of an event loop, which is deprecated in Python 3.10 and will be removed in a future version of Python. At that time `AnyThreadEventLoopPolicy` will no longer be useful. If you are relying on it, use `asyncio.new_event_loop` or `asyncio.run` explicitly in any non-main threads that need event loops.

class tornado.platform.asyncio.SelectorThread(real_loop: AbstractEventLoop)

  Define `add_reader` methods to be called in a background select thread.

  Instances of this class start a second thread to run a selector. This thread is completely hidden from the user; all callbacks are run on the wrapped event loop’s thread.

  Typically used via `AddThreadSelectorEventLoop`, but can be attached to a running asyncio loop.

class tornado.platform.asyncio.AddThreadSelectorEventLoop(real_loop: AbstractEventLoop)

  Wrap an event loop to add implementations of the `add_reader` method family.

  Instances of this class start a second thread to run a selector. This thread is completely hidden from the user; all callbacks are run on the wrapped event loop’s thread.

  This class is used automatically by Tornado; applications should not need to refer to it directly.

  It is safe to wrap any event loop with this class, although it only makes sense for event loops that do not implement the `add_reader` family of methods themselves (i.e. `WindowsProactorEventLoop`)

  Closing the `AddThreadSelectorEventLoop` also closes the wrapped event loop.