Open issues: signals, timeouts. Reminder: factories can be partial funcs.

pep-3156.txt

@@ -269,12 +269,16 @@ Some methods in the standard conforming interface return Futures:
   Creates a transport and a protocol and ties them together.  Returns
   a Future whose result on success is a (transport, protocol) pair.
   The protocol is created by calling ``protocol_factory()`` without
-  arguments.  Note that when the Future completes, the protocol's
+  arguments(*).  Note that when the Future completes, the protocol's
   ``connection_made()`` method has not yet been called; that will
   happen when the connection handshake is complete.  When it is
   impossible to connect to the given host and port, the Future will
   raise an exception instead.
 
+  (*) There is no requirement that ``protocol_factory`` is a class.
+  If your protocol class needs to have specific arguments passed to
+  its constructor, you can use ``lambda`` or ``functools.partial()``.
+
   Optional keyword arguments:
 
   - ``family``, ``type``, ``proto``, ``flags``: Address familty,
@@ -292,10 +296,12 @@ Some methods in the standard conforming interface return Futures:
   loop that accepts connections.  Returns a Future that completes once
   the loop is set up to serve; its return value is None.  Each time a
   connection is accepted, ``protocol_factory`` is called without
-  arguments to create a protocol, a transport is created to represent
+  arguments(*) to create a protocol, a transport is created to represent
   the network side of the connection, and the two are tied together by
   calling ``protocol.connection_made(transport)``.
 
+  (*) See footnote above for ``create_transport()``.
+
   Optional keyword arguments:
 
   - ``family``, ``type``, ``proto``, ``flags``: Address familty,
@@ -894,6 +900,24 @@ Open Issues
   Finally, do we need support for unconnected datagram protocols?
   (That would mean wrappers for ``sendto()`` and ``recvfrom()``.)
 
+- Signal handling.  This is pretty UNIX-specific, but sometimes an
+  application needs to intercept signals.  It may be handy to have a
+  standard interface for this in the event loop, so everyone doesn't
+  have to reinvent this same wheel (with the same bugs).  It's
+  possible that this can be a thin wrapper on top of
+  ``call_soon_threadsafe()`` (assuming its implementation doesn't use
+  locks -- if it does, something different is needed, since a signal
+  handler may run while the thread is already holding a lock).
+
+- We may need APIs to control various timeouts.  E.g. we may want to
+  limit the time spent in DNS resolution, connecting, ssl handshake,
+  idle connection, close/shutdown, even per session.  Possibly it's
+  sufficient to add ``timeout`` keyword parameters to some methods,
+  and other timeouts can probably be implemented by clever use of
+  ``call_later()`` and ``Task.cancel()``.  But it's possible that some
+  operations need default timeouts, and we may want to change the
+  default for a specific operation globally (i.e., per event loop).
+
 - An EventEmitter in the style of NodeJS?  Or make this a separate
   PEP?  It's easy enough to do in user space, though it may benefit
   from standardization.  (See