From 3d35067db1b346637684d8eaa399e0fd811a12ef Mon Sep 17 00:00:00 2001
From: Guido van Rossum <guido@dropbox.com>
Date: Mon, 25 Nov 2013 14:54:28 -0800
Subject: [PATCH] Get rid of final TO DO items.  Remove now-redundant section
 on coroutines and protocols.

---
 pep-3156.txt | 58 ++++++++++++++++++++++++++++++++--------------------
 1 file changed, 36 insertions(+), 22 deletions(-)

diff --git a/pep-3156.txt b/pep-3156.txt
index a022682c8..a12a11380 100644
--- a/pep-3156.txt
+++ b/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