Get rid of final TO DO items. Remove now-redundant section on coroutines and protocols.
This commit is contained in:
parent
7619d7bfae
commit
3d35067db1
58
pep-3156.txt
58
pep-3156.txt
|
@ -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
|
||||
|
|
Loading…
Reference in New Issue