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

Activity

1. vitaly-krugl commented on Mar 26, 2018

   

   vitaly-kruglmannequin

   on Mar 26, 2018

   MannequinAuthor

   More actions

   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?
2. vitaly-krugl

   added

   topic-asyncio

   on Mar 26, 2018
3. njsmith commented on Mar 27, 2018

   

   njsmith

   on Mar 27, 2018

   Contributor

   More actions

   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.
4. benjaminp commented on Apr 14, 2018

   

   benjaminp

   on Apr 14, 2018

   Contributor

   More actions

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

   transferred this issue fromon Apr 10, 2022
6. kumaraditya303 commented on Jun 19, 2022

   

   kumaraditya303

   on Jun 19, 2022

   Contributor

   More actions

   This is not reproducible on main hence closing.
7. kumaraditya303

   closed this as not plannedon Jun 19, 2022