Get rid of final TO DO items. Remove now-redundant section on coroutines and protocols.

This commit is contained in:
Guido van Rossum 2013-11-25 14:54:28 -08:00
parent 7619d7bfae
commit 3d35067db1
1 changed files with 36 additions and 22 deletions

View File

@ -1664,27 +1664,12 @@ implemented by the ``Task`` and ``Future`` classes using only the
public interface of the event loop, so it will work with third-party
event loop implementations, too.
Coroutines and Protocols
------------------------
The best way to use coroutines to implement an Internet protocol such
as FTP is probably to use a streaming buffer that gets filled by
``data_received()`` and can be read asynchronously using methods like
``read(n)`` and ``readline()`` that are coroutines or return a Future.
When the connection is closed, ``read()`` should eventually produce
``b''``, or raise an exception if ``connection_closed()`` is called
with an exception.
To write a response, the ``write()`` method (and friends) on the
transport can be used -- these do not return Futures. A standard
protocol implementation should be provided that sets this up and kicks
off the coroutine when ``connection_made()`` is called.
Convenience Utilities
---------------------
A few functions and classes are provided to simplify the writing of
basic stream-based clients and servers. Thes are:
basic stream-based clients and servers, such as FTP or HTTP. Thes
are:
- ``asyncio.open_connection(host, port)``: A wrapper for
``EventLoop.create_connection()`` that does not require you to
@ -1842,14 +1827,43 @@ The following classes and exceptions are provided by ``asyncio.queues``.
respectively.
TO DO
=====
Miscellaneous
=============
- Document all places that take a ``loop`` keyword argument.
Logging
-------
- Document ``logger`` object.
All logging performed by the ``asyncio`` package uses a single
``logging.Logger`` object, ``asyncio.logger``. To customize logging
you can use the standard ``Logger`` API on this object. (Do not
replace the object though.)
- Document ``SIGCHILD`` handling API.
``SIGCHLD`` handling on UNIX
----------------------------
Efficient implementation of the ``process_exited()`` method on
subprocess protocols requires a ``SIGCHLD`` signal handler. However,
signal handlers can only be set on the event loop associated with the
main thread. In order to support spawning subprocesses from event
loops running in other threads, a mechanism exists to allow sharing a
``SIGCHLD`` handler between multiple event loops. There are two
additional functions, ``asyncio.get_child_watcher()`` and
``asyncio.set_child_watcher()``, and corresponding methods on the
event loop policy.
There are two child watcher implementation classes,
``FastChildWatcher`` and ``SafeChildWatcher``. Both use ``SIGCHLD``.
The ``SafeChildWatcher`` class is used by default; it is inefficient
when many subprocesses exist simultaneously. The ``FastChildWatcher``
class is efficient, but it may interfere with other code (either C
code or Python code) that spawns subprocesses without using an
``asyncio`` event loop. If you are sure you are not using other code
that spawns subprocesses, to use the fast implementation, run the
following in your main thread::
watcher = asyncio.FastChildWatcher()
asyncio.set_child_watcher(watcher)
# TBD: Is a call to watcher.attach_loop() needed?
Wish List