From 1c38ea5dc31e51304ffb488c9f3bee507675760a Mon Sep 17 00:00:00 2001 From: Guido van Rossum Date: Fri, 10 May 2013 16:09:48 -0700 Subject: [PATCH] Move wrap_future() out of EventLoop. Document local_addr. --- pep-3156.txt | 22 +++++++++++++++++----- 1 file changed, 17 insertions(+), 5 deletions(-) diff --git a/pep-3156.txt b/pep-3156.txt index 4645fbafb..c718c4fb8 100644 --- a/pep-3156.txt +++ b/pep-3156.txt @@ -406,10 +406,6 @@ Thread interaction signal-safe; if you want to handle signals, use ``add_signal_handler()`` described below. -- ``wrap_future(future)``. This takes a PEP 3148 Future (i.e., an - instance of ``concurrent.futures.Future``) and returns a Future - compatible with the event loop (i.e., a ``tulip.Future`` instance). - - ``run_in_executor(executor, callback, *args)``. Arrange to call ``callback(*args)`` in an executor (see PEP 3148). Returns a Future whose result on success is the return value of that call. This is @@ -424,6 +420,9 @@ Thread interaction ``Executor`` instance or ``None``, in order to reset the default executor. +See also the ``wrap_future()`` function described in the section about +Futures. + Internet name lookups ''''''''''''''''''''' @@ -518,6 +517,12 @@ use a different transport and protocol interface. arguments. If this is given, host and port must be omitted; otherwise, host and port are required. + - ``local_addr``: If given, a ``(host, port)`` tuple used to bind + the socket to locally. This is rarely needed but on multi-homed + servers you occasionally need to force a connection to come from a + specific address. This is how you would do that. The host and + port are looked up using ``getaddrinfo()``. + - ``start_serving(protocol_factory, host, port, **kwds)``. Enters a serving loop that accepts connections. This is a Task that completes once the serving loop is set up to serve. The return @@ -892,12 +897,19 @@ In the future (pun intended) we may unify ``tulip.Future`` and ``concurrent.futures.Future``, e.g. by adding an ``__iter__()`` method to the latter that works with ``yield from``. To prevent accidentally blocking the event loop by calling e.g. ``result()`` on a Future -that's not don yet, the blocking operation may detect that an event +that's not done yet, the blocking operation may detect that an event loop is active in the current thread and raise an exception instead. However the current PEP strives to have no dependencies beyond Python 3.3, so changes to ``concurrent.futures.Future`` are off the table for now. +There is one public function related to Futures. It is: + +- ``wrap_future(future)``. This takes a PEP 3148 Future (i.e., an + instance of ``concurrent.futures.Future``) and returns a Future + compatible with the event loop (i.e., a ``tulip.Future`` instance). + + Transports ----------