[Async-sig] asyncio.timeout() is not portable

[Ben Darnell]

On Sun, Jun 5, 2016 at 1:02 PM, Guido van Rossum <guido at python.org> wrote:

> So in the case of that Tornado example, who does the sleeping (or how
> is the exception scheduled)?


The exception is scheduled with IOLoop.add_timeout (equivalent to asyncio's
call_later). One difference between the two is that Tornado's with_timeout
creates a new future (and a new coroutine runner) instead of cancelling the
input future.

The code is here:
https://github.com/tornadoweb/tornado/blob/11bd951cc04747c0f03c71575d004f322950a5c3/tornado/gen.py#L835


> We may not be able to retract this from
> 3.5.2 (RC1 goes out next weekend) but asyncio is still provisional
> until the 3.6 feature freeze in September. What's a better design?
>

I prefer a function that wraps an awaitable (as in Tornado's
implementation), but this does have a performance impact. If we want to
avoid that, then I think an `async with` context manager would be a better
choice than an ordinary context manager, but I'd like to have a proof of
concept implementation that works across asyncio and at least one other
platform before committing to that design.



> (FWIW asyncio.timeout() takes an optional loop parameter, but that's
> probably not helpful.)
>

No, it's not helpful because event loops and coroutine runners are
independent. It's easy to find the current event loop (there are globals
for that), but you can't really interact with the coroutine runner except
via yield/await (unless we introduce new globals for this purpose)

-Ben


>
> On Sun, Jun 5, 2016 at 8:56 AM, Ben Darnell <ben at bendarnell.com> wrote:
> > It has come to my attention (
> https://github.com/KeepSafe/aiohttp/issues/877)
> > that Python 3.5.2 (!) introduced a new context manager asyncio.timeout,
> > which attaches a timeout to the current asyncio.Task. Any library or
> > application that uses this feature will not be portable to other
> coroutine
> > runners.
> >
> >     with asyncio.timeout(1):
> >         result = await aiohttp.get('http://www.example.com')
> >
> > It's difficult to make this interface portable. We'd need to introduce a
> > global thread-specific object that all of the coroutine runners could
> > register the current task on, and define an interface that
> asyncio.timeout
> > would call on that object to set the timeout. We could get rid of the
> global
> > if the context manager used `async with` instead of `with`, since that
> would
> > give us a way to communicate with the coroutine runner directly, but the
> net
> > result is still that each runner needs to implement hooks for this
> feature
> > (the hooks may or may not be generalizable to other features in the
> future).
> >
> > If our goal is portability across coroutine runners, then
> asyncio.timeout()
> > needs to go back to the drawing board. If the goal is to extend
> asyncio.Task
> > to be the one true coroutine runner then we could leave it as-is.
> >
> > For comparison, Tornado's equivalent to asyncio.timeout is
> > tornado.gen.with_timeout(), and it has no special interactions with the
> > coroutine runner:
> >
> >     result = await with_timeout(timedelta(seconds=1),
> >                      convert_yielded(aiohttp.get("http://www.example.com
> ")))
> >
> > (The convert_yielded call won't be needed in the next release of Tornado.
> > The use of timedelta is because Tornado prefers absolute deadlines
> instead
> > of relative timeouts, so that's how plain numbers are interpreted).
> >
> > -Ben
> >
> > _______________________________________________
> > Async-sig mailing list
> > Async-sig at python.org
> > https://mail.python.org/mailman/listinfo/async-sig
> > Code of Conduct: https://www.python.org/psf/codeofconduct/
>
>
>
> --
> --Guido van Rossum (python.org/~guido)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/async-sig/attachments/20160605/d3240423/attachment-0001.html>