asyncio question

[Kyle Stanley]

 On Tue, Nov 3, 2020 at 3:27 AM Frank Millman <frank at chagford.com> wrote:

> It works, and it does look neater. But I want to start some background
> tasks before starting the server, and cancel them on Ctrl+C.
>
> Using the 'old' method, I can wrap 'loop.run_forever()' in a
> try/except/finally, check for KeyboardInterrupt, and run my cleanup in
> the 'finally' block.
>
> Using the 'new' method, KeyboardInterrupt is not caught by
> 'server.serve_forever()' but by 'asyncio.run()'. It is too late to do
> any cleanup at this point, as the loop has already been stopped.
>
> Is it ok to stick to the 'old' method, or is there a better way to do this.
>

It's fine to stick with the older method in your case, as there's nothing
inherently wrong with continuing to use it. `asyncio.run()` is largely a
convenience function that takes care of some finalization/cleanup steps
that are often forgotten (cancelling remaining tasks, closing event loop's
default ThreadPoolExecutor, closing async generators, etc). If you want to
use custom KeyboardInterrupt handling and still use asyncio.run(), you can
either (a) use `loop.add_signal_handler()` or (b) make a slightly modified
local version of `asyncio.run()` that has your desired KeyboardInterrupt
behavior, based roughly on
https://github.com/python/cpython/blob/master/Lib/asyncio/runners.py.

However, using `loop.run_until_complete()` instead of `asyncio.run()` is
also perfectly fine, especially in existing code that still works without
issue. It just leaves the author with a bit more responsibility when it
comes to resource finalization and dealing with the event loop in general
(which can add some extra cognitive burden and room for error, particularly
when dealing with multiple event loops or threads). But it's reasonably
common to continue using `loop.run_until_complete()` in situations where
the default `asyncio.run()` behavior isn't what you need/want, such as your
case.