RuntimeError('Event loop is closed') after cancelling getaddrinfo and closing loop

[vitaly-krugl]

BPO	33148
Nosy	@benjaminp, @njsmith, @asvetlov, @1st1, @vitaly-krugl
PRs	bpo-33184: Update Windows build to use OpenSSL 1.0.2o (GH-6464) #6474

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2018-03-26.22:50:43.242>
labels = ['expert-asyncio']
title = "RuntimeError('Event loop is closed') after cancelling getaddrinfo and closing loop"
updated_at = <Date 2018-04-14.22:05:05.470>
user = 'https://github.com/vitaly-krugl'

bugs.python.org fields:

activity = <Date 2018-04-14.22:05:05.470>
actor = 'benjamin.peterson'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['asyncio']
creation = <Date 2018-03-26.22:50:43.242>
creator = 'vitaly.krug'
dependencies = []
files = []
hgrepos = []
issue_num = 33148
keywords = ['patch']
message_count = 3.0
messages = ['314484', '314488', '315306']
nosy_count = 5.0
nosy_names = ['benjamin.peterson', 'njs', 'asvetlov', 'yselivanov', 'vitaly.krug']
pr_nums = ['6474']
priority = 'normal'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = None
url = 'https://bugs.python.org/issue33148'
versions = ['Python 3.6']

[vitaly-krugl]

I see this exception on the terminal:

exception calling callback for <Future at 0x10722ee48 state=finished returned list>
Traceback (most recent call last):
  File "/usr/local/Cellar/python/3.6.4_3/Frameworks/Python.framework/Versions/3.6/lib/python3.6/concurrent/futures/_base.py", line 324, in _invoke_callbacks
    callback(self)
  File "/usr/local/Cellar/python/3.6.4_3/Frameworks/Python.framework/Versions/3.6/lib/python3.6/asyncio/futures.py", line 414, in _call_set_state
    dest_loop.call_soon_threadsafe(_set_state, destination, source)
  File "/usr/local/Cellar/python/3.6.4_3/Frameworks/Python.framework/Versions/3.6/lib/python3.6/asyncio/base_events.py", line 620, in call_soon_threadsafe
    self._check_closed()
  File "/usr/local/Cellar/python/3.6.4_3/Frameworks/Python.framework/Versions/3.6/lib/python3.6/asyncio/base_events.py", line 357, in _check_closed
    raise RuntimeError('Event loop is closed')
RuntimeError: Event loop is closed

When executing this code:

import asyncio

while True:
    loop = asyncio.new_event_loop()

    coro = loop.getaddrinfo('www.google.com', 80)

    task = asyncio.ensure_future(coro, loop=loop)

    task.cancel()

    loop.call_soon_threadsafe(loop.stop)

    loop.run_forever()

    loop.close()

Shouldn't a cancelled operation go away (or at least pretend to go away) cleanly?

[njsmith]

Yeah, getaddrinfo isn't actually cancellable (because it's a blocking call that has to be run in a thread), but it's side-effect-free so if the user requests that it be cancelled then it's safe to return immediately while it keeps running in the background, and asyncio does so. But if we've already decided to discard the result then it's better to do that silently, like you say.

When trio hits this case, it does silently throw away the result: https://github.com/python-trio/trio/blob/aebb42888dd0978c3b74f8c9cdf8aec2ce2cbd73/trio/_threads.py#L372-L377
It's a little bit more obvious in trio's case because there we 100% know that if the call to trio.run has finished, then there's no-one listening for the result, and that the user has explicitly requested this behavior. In asyncio's case, I guess in theory someone could still be hoping the Future's done callback will be invoked even after the loop is closed. This seems unlikely though... and in general when the loop is closed then every other registered callback is silently discarded, so doing that for run_in_executor seems fine too.

[benjaminp]

New changeset bba2ba1 by Benjamin Peterson (Steve Dower) in branch '2.7':
bpo-33148: Update Windows build to use OpenSSL 1.0.2o
bba2ba1

[kumaraditya303]

This is not reproducible on main hence closing.