# HG changeset patch # Parent 50bfb0899095c22d9fa5b74d681889cefc59f250 diff -r 50bfb0899095 Doc/library/asyncio-dev.rst --- a/Doc/library/asyncio-dev.rst Sun Jun 21 10:47:20 2015 -0700 +++ b/Doc/library/asyncio-dev.rst Mon Jun 22 14:18:11 2015 +0000 @@ -99,7 +99,7 @@ :meth:`BaseEventLoop.call_soon_threadsafe` method should be used. Example to schedule a coroutine from a different thread:: - loop.call_soon_threadsafe(asyncio.async, coro_func()) + loop.call_soon_threadsafe(asyncio.ensure_future, coro_func()) Most asyncio objects are not thread safe. You should only worry if you access objects outside the event loop. For example, to cancel a future, don't call @@ -162,7 +162,8 @@ ---------------------------------------- When a coroutine function is called and its result is not passed to -:func:`async` or to the :meth:`BaseEventLoop.create_task` method, the execution +:func:`ensure_future` or to the +:meth:`BaseEventLoop.create_task` method, the execution of the coroutine object will never be scheduled which is probably a bug. :ref:`Enable the debug mode of asyncio ` to :ref:`log a warning ` to detect it. @@ -184,7 +185,7 @@ File "test.py", line 7, in test() -The fix is to call the :func:`async` function or the +The fix is to call the :func:`ensure_future` function or the :meth:`BaseEventLoop.create_task` method with the coroutine object. .. seealso:: diff -r 50bfb0899095 Doc/library/asyncio-eventloop.rst --- a/Doc/library/asyncio-eventloop.rst Sun Jun 21 10:47:20 2015 -0700 +++ b/Doc/library/asyncio-eventloop.rst Mon Jun 22 14:18:11 2015 +0000 @@ -36,7 +36,7 @@ Run until the :class:`Future` is done. If the argument is a :ref:`coroutine object `, it is wrapped by - :func:`async`. + :func:`ensure_future`. Return the Future's result, or raise its exception. diff -r 50bfb0899095 Doc/library/asyncio-protocol.rst --- a/Doc/library/asyncio-protocol.rst Sun Jun 21 10:47:20 2015 -0700 +++ b/Doc/library/asyncio-protocol.rst Mon Jun 22 14:18:11 2015 +0000 @@ -448,7 +448,8 @@ Coroutines and protocols ------------------------ -Coroutines can be scheduled in a protocol method using :func:`async`, but there +Coroutines can be scheduled in a protocol method +using :func:`ensure_future`, but there is no guarantee made about the execution order. Protocols are not aware of coroutines created in protocol methods and so will not wait for them. diff -r 50bfb0899095 Doc/library/asyncio-task.rst --- a/Doc/library/asyncio-task.rst Sun Jun 21 10:47:20 2015 -0700 +++ b/Doc/library/asyncio-task.rst Mon Jun 22 14:18:11 2015 +0000 @@ -52,7 +52,7 @@ In the case of a coroutine object, there are two basic ways to start it running: call ``yield from coroutine`` from another coroutine (assuming the other coroutine is already running!), or schedule its execution -using the :func:`async` function or the :meth:`BaseEventLoop.create_task` +using the :func:`ensure_future` function or the :meth:`BaseEventLoop.create_task` method. @@ -72,7 +72,7 @@ even if they are plain Python functions returning a :class:`Future`. This is intentional to have a freedom of tweaking the implementation of these functions in the future. If such a function is needed to be - used in a callback-style code, wrap its result with :func:`async`. + used in a callback-style code, wrap its result with :func:`ensure_future`. .. _asyncio-hello-world-coroutine: @@ -374,7 +374,7 @@ ` did not complete. It is probably a bug and a warning is logged: see :ref:`Pending task destroyed `. - Don't directly create :class:`Task` instances: use the :func:`async` + Don't directly create :class:`Task` instances: use the :func:`ensure_future` function or the :meth:`BaseEventLoop.create_task` method. This class is :ref:`not thread safe `.