Mailman 3 December 2017 - Async-sig

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

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 08 Dec '17

08 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 04 Dec '17

04 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

async await as basic paradigm - relation to delimited continuations ?
by Asmodehn Shade 02 Dec '17

02 Dec '17

Hi everyone, I have been working on distributed programming for a while now, however I was away from python land, and didnt get into the twisted/tornado/asyncio train until few years ago. While writing asyncio code and exploring different abstract computing paradigm (my recent hobby seems to be exploring new ways to do computing), I recently discover curio. I read a few github issues, and although I do enjoy experiments, I am also aware of the need for mathematical fundations in order for a project to be able to compose between projects and groups of people and ultimately scale and persist. As well as finding its own roots to support an ecosystem. I was wondering if there was someone on this mailing list versed enough in maths and computer science who could see some kind of association/relation between async/await and delimited continuations... and hopefully fomalize it somehow ? As a side effect, this might give some improvement ideas to curio ... The way I see it so far, very rough and naive : - the event loop is "doing the work", that is a sequence of delimited continuations. - async/await denotes how the work to be done can be composed (wrapping functions that already could compose by themselves to add additional runtime semantics), - tasks are like delimited continuations, and they will be ordered at runtime to execute in a specific sequence. Or am I completely misleaded ? If we scale this up and "distribute" it (actor model style), one actor can match one event-loop, and there are probably many association to draw there, that could indicate for curio (or libraries using it) if it is sensible or not to completely identify the event_loop to a thread... As a broad overview : 1) imperative concepts can be implemented from functional/math concepts (haskell - do notation, relation with category theory) 2) functional concept are currently implemented with imperative languages ( scheme interpreters, haskell compiler, etc. ) 3) looking as async programming and functional/math concepts these days, I am wondering how these relate, and how far down goes the rabbit hole... Thanks a lot for sharing your views on this :-). -- AlexV

1 0

Async-sig December 2017