tornado.platform.asyncio — Bridge between asyncio and Tornado

Bridges between the asyncio module and Tornado IOLoop.

New 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.

initialize(**kwargs: Any) → None

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.

initialize(**kwargs: Any) → None

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

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

New 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.

New 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())

New 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.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.