Mailman 3 - Async-sig

Cancelling a coroutine from a signal handler?
by Mark E. Haase 25 Apr '18

25 Apr '18

I am trying to understand some unexpected behavior in asyncio. My goal is to use a custom signal handler to cleanly unwind an asyncio program that has many different tasks running. Here's a simplified test case: 1 import asyncio, logging, random, signal, sys 2 3 logging.basicConfig(level=logging.DEBUG) 4 logger = logging.getLogger() 5 6 async def main(): 7 try: 8 await asyncio.Event().wait() 9 except asyncio.CancelledError: 10 logger.info('cancelled main()') 11 # cleanup logic 12 13 def handle_sigint(signal, frame): 14 global sigint_count 15 global main_coro 16 sigint_count += 1 17 if sigint_count == 1: 18 logger.warn('Received interrupt: shutting down...') 19 main_coro.throw(asyncio.CancelledError()) 20 # missing event loop logic? 21 else: 22 logger.warn('Received 2nd interrupt: exiting!') 23 main_coro.throw(SystemExit(1)) 24 25 sigint_count = 0 26 signal.signal(signal.SIGINT, handle_sigint) 27 loop = asyncio.get_event_loop() 28 main_coro = main() 29 try: 30 loop.run_until_complete(main_coro) 31 except StopIteration: 32 logger.info('run_until_complete() finished') The main() function is a placeholder that represents some long running task, e.g. a server that is waiting for new connections. The handle_sigint() function is supposed to attempt to cancel main() so that it can gracefully exit, but if it receives a second interrupt, then the process exits immediately. Here's an example running the program and then typing Ctrl+C. $ python test.py DEBUG:asyncio:Using selector: EpollSelector ^CWARNING:root:Received interrupt: shutting down... INFO:root:cancelled main() INFO:root:run_until_complete() finished This works as I expect it to. Of course my cleanup logic (line 10) isn't actually doing anything. In a real server, I might want to send goodbye messages to connected clients. To mock this behavior, I'll modify line 11: 11 await asyncio.sleep(0) Surprisingly, now my cleanup code hangs: $ python test.py DEBUG:asyncio:Using selector: EpollSelector ^CWARNING:root:Received interrupt: shutting down... INFO:root:cancelled main() ^CWARNING:root:Received 2nd interrupt: exiting! Notice that the program doesn't exit after the first interrupt. It enters the exception handler and appears to hang on the await expression on line 11. I have to interrupt it a second time, which throws SystemExit instead. I puzzled over this for quite some time until I realized that I can force main() to resume by changing line 20: 20 main_coro.send(None) With this change, the interrupt causes the cleanup logic to run to completion and the program exits normally. Of course, if I add a second await expression: 11 await asyncio.sleep(0); await asyncio.sleep(0) Then I also have to step twice: 20 main_coro.send(None); main_coro.send(None) My mental model of how the event loop works is pretty poor, but I roughly understand that the event loop is responsible for driving coroutines. It appears here that the event loop has stopped driving my main() coroutine, and so the only way to force it to complete is to call send() from my code. Can somebody explain *why* the event loop is not driving my coroutine? Is this a bug or am I missing something conceptually? More broadly, handling KeyboardInterrupt in async code seems very tricky, but I also cannot figure out how to make this interrupt approach work. Is one of these better than the other? What is the best practice here? Would it be terrible to add `while True: main_coro.send(None)` to my signal handler? Thanks, Mark

3 4

asyncio.Lock equivalent for multiple processes
by Ludovic Gasc 17 Apr '18

17 Apr '18

Hi, I'm looking for a equivalent of asyncio.Lock ( https://docs.python.org/3/library/asyncio-sync.html#asyncio.Lock) but shared between several processes on the same server, because I'm migrating a daemon from mono-worker to multi-worker pattern. For now, the closest solution in term of API seems aioredlock: https://github.com/joanvila/aioredlock#aioredlock But I'm not a big fan to use polling nor with a timeout because the lock I need is very critical, I prefer to block the code than unlock with timeout. Do I miss a new awesome library or do you have an easier approach ? Thanks for your responses. -- Ludovic Gasc (GMLudo)

5 7

Simplifying stack traces for tasks?
by Mark E. Haase 13 Apr '18

13 Apr '18

If an exception is thrown while the `asyncio` event loop is running, the stack trace is pretty complicated. Here's an example: Traceback (most recent call last): File "sample_client.py", line 616, in <module> loop.run_until_complete(main_task) File "/usr/lib/python3.6/asyncio/base_events.py", line 437, in run_until_complete self.run_forever() File "/usr/lib/python3.6/asyncio/base_events.py", line 405, in run_forever self._run_once() File "/usr/lib/python3.6/asyncio/base_events.py", line 1382, in _run_once handle._run() File "/usr/lib/python3.6/asyncio/events.py", line 126, in _run self._callback(*self._args) File "/usr/lib/python3.6/asyncio/tasks.py", line 315, in _wakeup self._step() File "/usr/lib/python3.6/asyncio/tasks.py", line 239, in _step result = coro.send(None) File "sample_client.py", line 319, in main await actions[args.action](args, socket) File "/usr/lib/python3.6/asyncio/coroutines.py", line 105, in __next__ return self.gen.send(None) File "sample_client.py", line 558, in sync_job await asyncio.sleep(args.delay) File "/usr/lib/python3.6/asyncio/coroutines.py", line 105, in __next__ return self.gen.send(None) File "/usr/lib/python3.6/asyncio/tasks.py", line 522, in sleep future, result) File "/usr/lib/python3.6/asyncio/base_events.py", line 525, in call_later timer = self.call_at(self.time() + delay, callback, *args) File "/usr/lib/python3.6/asyncio/base_events.py", line 541, in call_at timer = events.TimerHandle(when, callback, args, self) File "/usr/lib/python3.6/asyncio/events.py", line 148, in __init__ super().__init__(callback, args, loop) File "/usr/lib/python3.6/asyncio/events.py", line 92, in __init__ self._source_traceback = traceback.extract_stack(sys._getframe(1)) File "/usr/lib/python3.6/traceback.py", line 207, in extract_stack stack = StackSummary.extract(walk_stack(f), limit=limit) File "/usr/lib/python3.6/traceback.py", line 352, in extract filename, lineno, name, lookup_line=False, locals=f_locals)) KeyboardInterrupt Most of the stack frames are inside asyncio (_run, _wakeup, _step) and reveal the mechanics of the event loop. The stack trace would be a lot easier to read (and more similar to a stack trace of an equivalent synchronous program) if it looked like this: Traceback (most recent call last): File "sample_client.py", line 616, in <module> loop.run_until_complete(main_task) ... File "sample_client.py", line 319, in main await actions[args.action](args, socket) ... File "sample_client.py", line 558, in sync_job await asyncio.sleep(args.delay) KeyboardInterrupt I recognize that the event loop mechanics are probably useful in some circumstances, but in my experience working with asyncio for the last year, I've found the stack traces are generally too noisy. For a while, I was pasting stack traces into a text editor and cleaning them up by hand, but a few months ago I wrote a custom excepthook that generates stack traces similar to the one above. def async_excepthook(type_, exc, tb): cause_exc = None cause_str = None if exc.__cause__ is not None: cause_exc = exc.__cause__ cause_str = 'The above exception was the direct cause ' \ 'of the following exception:' elif exc.__context__ is not None and not exc.__suppress_context__: cause_exc = exc.__context__ cause_str = 'During handling of the above exception, ' \ 'another exception occurred:' if cause_exc: async_excepthook(type(cause_exc), cause_exc, cause_exc.__traceback__) if cause_str: print('\n{}\n'.format(cause_str)) print('Async Traceback (most recent call last):') for frame in traceback.extract_tb(tb): head, tail = os.path.split(frame.filename) if (head.endswith('asyncio') or tail == 'traceback.py') and \ frame.name.startswith('_'): print(' ...') continue print(' File "{}", line {}, in {}' .format(frame.filename, frame.lineno, frame.name)) print(' {}'.format(frame.line)) print('{}: {}'.format(type_.__name__, exc)) The meat of it is towards the bottom, "if head.endswith('asyncio')..."There are a lot of debatable details and this implementation is pretty hacky and clumsy, but I have found it valuable in my own usage, and I haven't yet missed the omitted stack frames. I'm posting here to get constructive criticism on the concept and would also like to hear if Curio or Trio have done anything like this. (Based on a quick skim of the docs, I don't think they are.) I might publish a PyPI package if anybody is interested. Cheers, Mark

4 7

avoiding accidentally calling blocking code
by Chris Jerdonek 14 Feb '18

14 Feb '18

Hi, This is a general Python async question I've had that I haven't seen a discussion of. Do people know of any techniques other than manually inspecting code line by line to find out if you're accidentally making a raw call to a blocking function in a coroutine? Related to this, again, outside of inspecting the external source code, is there any way to know if a function you're calling (e.g. in someone else's library or in the standard lib) has the potential of blocking? What would be the way of detecting something like this if it made its way into "production"? What would be some of the symptoms? --Chris

4 5

Blog post: Timeouts and cancellation for humans
by Nathaniel Smith 16 Jan '18

16 Jan '18

Hi all, Folks here might be interested in this new blog post: https://vorpus.org/blog/timeouts-and-cancellation-for-humans/ It's a detailed discussion of pitfalls and design-tradeoffs in APIs for timeout and cancellation, and has a proposal for handling them in a more Pythonic way. Any feedback welcome! -n -- Nathaniel J. Smith -- https://vorpus.org

5 12

Asyncio loop instrumentation
by Pau Freixes 02 Jan '18

02 Jan '18

Hi, foks First of all, I hope that you have had a good 2017 and I wish for your the best for 2018. This email is the continuation of a plan B of the first proposal [1] to articulate a way to measure the load of the Asyncio loop. The main objections with the first implementation were focused on the technical debt that the implementation imposed, taking into account that the feature was definitely out of the main scope of the Asyncio loop goal. Nathaniel proposed a plan B based on implement some kind of instrumentalization that will allow developers to implement features such as the load one. I put off the plan for a while having, wrongly, feeling that an implementation of the loop wired with the proper events will impact with the loop performance. Far away from the reality, the suggested implementation in terms of performance penalty is almost negligible, at least for what I considered the happy path which means that there are no instruments listening for these events. These new implementation of the load method - remember that it returns a load factor between 0.0 and 1.0 that inform you about how bussy is your loop - based on an instrument can be checked with the following snippet: async def coro(loop, idx): await asyncio.sleep(idx % 10) if load() > 0.9: return False start = loop.time() while loop.time() - start < 0.02: pass return True async def run(loop, n): tasks = [coro(loop, i) for i in range(n)] results = await asyncio.gather(*tasks) abandoned = len([r for r in results if not r]) print("Load reached for {} coros/seq: {}, abandoned {}/{}".format(n/10, load(), abandoned)) async def main(loop): await run(loop, 100) loop = asyncio.get_event_loop() loop.add_instrument(LoadInstrument) loop.run_until_complete(main(loop)) The `LoadInstrument` [2] meets the contract of the LoopInstrument[3] that allow it to listen the proper loop signals that will be used to calculate the load of the loop. For this proposal [4], POC, I've preferred make a reduced list of events: * `loop_start` : Executed when the loop starts for the first time. * `tick_start` : Executed when a new loop tick is started. * `io_start` : Executed when a new IO process starts. * `io_end` : Executed when the IO process ends. * `tick_end` : Executed when the loop tick ends. * `loop_stop` : Executed when the loop stops. The idea of giving just this short list of events try to avoid over complicate third loops implementations, implementing the minimum set of events that a typical reactor has to implement. I would like to gather your feedback for this new approximation, and if you believe that it might be interesting which are the next steps that must be done. Cheers, [1] https://mail.python.org/pipermail/async-sig/2017-August/000382.html [2] https://github.com/pfreixes/asyncio_load_instrument/blob/master/asyncio_loa… [3] https://github.com/pfreixes/cpython/blob/asyncio_loop_instrumentation/Lib/a… [4] https://github.com/pfreixes/cpython/commit/adc3ba46979394997c40aa89178b4724… -- --pau

4 7

task.result() and exception traceback display
by Chris Jerdonek 25 Dec '17

25 Dec '17

Hi, I noticed that if a task in asyncio raises an exception, then the displayed traceback can be "polluted" by intermediate calls to task.result(). Also, the calls to task.result() can appear out of order relative to each other and to other lines. Here is an example: import asyncio async def raise_error(): raise ValueError() async def main(): task = asyncio.ensure_future(raise_error()) try: await task # call 1 except Exception: pass try: task.result() # call 2 except Exception: pass task.result() # call 3 asyncio.get_event_loop().run_until_complete(main()) The above outputs-- Traceback (most recent call last): File "test.py", line 24, in <module> asyncio.get_event_loop().run_until_complete(main()) File "/Users/.../3.6.4rc1/lib/python3.6/asyncio/base_events.py", line 467, in run_until_complete return future.result() File "test.py", line 21, in main task.result() # call 3 File "test.py", line 17, in main task.result() # call 2 File "test.py", line 12, in main await task # call 1 File "test.py", line 5, in raise_error raise ValueError() ValueError Notice that the "call 2" line appears in the traceback, even though it doesn't come into play in the exception. Also, the lines don't obey the "most recent call last" rule. If this rule were followed, it should be something more like-- Traceback (most recent call last): File "test.py", line 24, in <module> asyncio.get_event_loop().run_until_complete(main()) File "/Users/.../3.6.4rc1/lib/python3.6/asyncio/base_events.py", line 467, in run_until_complete return future.result() File "test.py", line 12, in main await task # call 1 File "test.py", line 5, in raise_error raise ValueError() File "test.py", line 17, in main task.result() # call 2 File "test.py", line 21, in main task.result() # call 3 ValueError If people agree there's an issue along these lines, I can file an issue in the tracker. I didn't seem to find one when searching for open issues with search terms like "asyncio traceback". Thanks, --Chris

2 2

APIs for high-bandwidth large I/O?
by Antoine Pitrou 07 Dec '17

07 Dec '17

Hi, I am currently looking into ways to optimize large data transfers for a distributed computing framework (https://github.com/dask/distributed/). We are using Tornado but the question is more general, as it turns out that certain kinds of API are an impediment to such optimizations. To put things short, there are a couple benchmarks discussed here: https://github.com/tornadoweb/tornado/issues/2147#issuecomment-337187960 - for Tornado, this benchmark: https://gist.github.com/pitrou/0f772867008d861c4aa2d2d7b846bbf0 - for asyncio, this benchmark: https://gist.github.com/pitrou/719e73c1df51e817d618186833a6e2cc Both implement a trivial form of framing using the "preferred" APIs of each framework (IOStream for Tornado, Protocol for asyncio), and then benchmark it over 100 MB frames using a simple echo client/server. The results (on Python 3.6) are interesting: - vanilla asyncio achieves 350 MB/s - vanilla Tornado achieves 400 MB/s - asyncio + uvloop achieves 600 MB/s - an optimized Tornado IOStream with a more sophisticated buffering logic (https://github.com/tornadoweb/tornado/pull/2166) achieves 700 MB/s The latter result is especially interesting. uvloop uses hand-crafted Cython code + the C libuv library, still, a pure Python version of Tornado does better thanks to an improved buffering logic in the streaming layer. Even the Tornado result is not ideal. When profiling, we see that 50% of the runtime is actual IO calls (socket.send and socket.recv), but the rest is still overhead. Especially, buffering on the read side still has costly memory copies (b''.join calls take 22% of the time!). For a framed layer, you shouldn't need so many copies. Once you've read the frame length, you can allocate the frame upfront and read into it. It is at odds, however, with the API exposed by asyncio's Protocol: data_received() gives you a new bytes object as soon as data arrives. It's already too late: a spurious memory copy will have to occur. Tornado's IOStream is less constrained, but it supports too many read schemes (including several types of callbacks). So I crafted a limited version of IOStream (*) that supports little functionality, but is able to use socket.recv_into() when asked for a given number of bytes. When benchmarked, this version achieves 950 MB/s. This is still without C code! (*) see https://github.com/tornadoweb/tornado/compare/master...pitrou:stream_readin… When profiling that limited version of IOStream, we see that 68% of the runtime is actual IO calls (socket.send and socket.recv_into). Still, 21% of the total runtime is spent allocating a 100 MB buffer for each frame! That's 70% of the non-IO overhead! Whether or not there are smart ways to reuse that writable buffer depends on how the application intends to use data: does it throw it away before the next read or not? It doesn't sound easily doable in the general case. So I'm wondering which kind of APIs async libraries could expose to make those use cases faster. I know curio and trio have socket objects which would probably fit the bill. I don't know if there are higher-level concepts that may be as adequate for achieving the highest performance. Also, since asyncio is the de facto standard now, I wonder if asyncio might grow such a new API. That may be troublesome: asyncio already has Protocols and Streams, and people often complain about its extensive API surface that's difficult for beginners :-) Addendum: asyncio streams ------------------------- I didn't think asyncio streams would be a good solution, but I still wrote a benchmark variant for them out of curiosity, and it turns out I was right. The results: - vanilla asyncio streams achieve 300 MB/s - asyncio + uvloop streams achieve 550 MB/s The benchmark script is at https://gist.github.com/pitrou/202221ca9c9c74c0b48373ac89e15fd7 Regards Antoine.

5 7

ANN: Trio v0.2.0 released
by Nathaniel Smith 07 Dec '17

07 Dec '17

Hi all, I'm proud to announce the release of Trio v0.2.0. Trio is a new async concurrency library for Python that's obsessed with usability and correctness -- we want to make it easy to get things right. This is the second public release, and it contains major new features and bugfixes from 14 contributors. You can read the full release notes here: https://trio.readthedocs.io/en/latest/history.html#trio-0-2-0-2017-12-06 Some things I'm particularly excited about are: - Comprehensive support for async file I/O - The new 'nursery.start' method for clean startup of complex task trees - The new high-level networking API -- this is roughly the same level of abstraction as twisted/asyncio's protocols/transports. Includes luxuries like happy eyeballs for most robust client connections, and server helpers that integrate with nursery.start. - Complete support for using SSL/TLS encryption over arbitrary transports. You can even do SSL-over-SSL, which is useful for HTTPS proxies and AFAIK not supported by any other Python library. - Task-local storage. - Our new contributing guide: https://trio.readthedocs.io/en/latest/contributing.html To get started with Trio, the best place to start is our tutorial: https://trio.readthedocs.io/en/latest/tutorial.html It doesn't assume any prior familiarity with concurrency or async/await. Share and enjoy, -n -- Nathaniel J. Smith -- https://vorpus.org

1 0

subclassing CancelledError
by Chris Jerdonek 03 Dec '17

03 Dec '17

Hi, I want to ask how people feel about the following. If you raise a subclass of CancelledError from within a task and then call task.result(), CancelledError is raised rather than the subclass. Here is some code to illustrate: class MyCancelledError(CancelledError): pass async def raise_my_cancel(): raise MyCancelledError() task = asyncio.ensure_future(raise_my_cancel()) try: await task except Exception: pass assert task.cancelled() # Raises CancelledError and not MyCancelledError. task.result() Does this seem right to people? Is there a justification for this? If it would help for the discussion, I could provide a use case. Thanks a lot, --Chris

3 4