Asyncio "laundry list"

[agronholm]

I think we ought to start collecting a wish list of asyncio improvements that we would like to see. I'm starting the list with the items I can recall off the top of my hat and update it as suggestions come in:

• task groups + exception groups → in Python 3.11
• cancel scopes → won't do
• always give tasks an opportunity to respond to cancellation (as it is written in the asyncio docs) → won't do
• level-triggered cancellation (always raise CancelledError for cancelled tasks at checkpoints when their current cancel scope has been cancelled) → won't do
• trio-like instrumentation → okayed by Yury
• overriding clock control, like with trio's MockClock → okayed by Yury
• better signal handling control (perhaps ability to set multiple signal handlers, or at least the ability to get the current signal handler)
• a procedural way to use UDP sockets (without having to involve transports and protocols) → in Python 3.11
• an explicit way to use either threads or subprocesses (the current "executor" system does not distinguish between the two which is totally insane since they have vastly different constraints) (not an issue since 3.9+?)
• using a higher resolution timer on Windows (this was an issue IIRC)
• better KeyboardInterrupt handling?
• make Context propagation work more trio-like? Ref: to/from_thread and contextvars #363 → need to determine "correct" semantics; njs said trio may be doing this wrong → ought to be fixed in trio

Related language improvements we would like to see:

• add a public module for Windows overlapped I/O (make _overlapped public and document it)
• make async_generator_anext and async_generator_athrow real inspect.iscoroutines that support inspect.getcoroutinestate → already implemented or at least in the works?

[graingert]

• edge vs level cancellation
• always wrap task coros with an async def coro - async_generator_anext is missing .cr_await etc.
• make async_generator_anext and async_generator_athrow real inspect.iscoroutines that support inspect.getcoroutinestate
• only cancel a task after a task has an opportunity to suppress it (this is the documented behaviour https://docs.python.org/3/library/asyncio-task.html#asyncio.Task.cancel)
• tasks created as part of asyncio.runners._cancel_all_tasks are aborted
• tasks created as part of loop.shutdown_async_gens are aborted
• cancelling await stream.wait_closed() breaks a protocol for other users

[graingert]

edge vs level cancellation
only cancel a task after a task has an opportunity to suppress it (this is the documented behaviour)

Aren't these the same thing?

no - it's two slightly different aspects of trio cancellation

always wrap task coros with an async def coro - async_generator_anext is missing .cr_await etc.

Sounds like something to be fixed on the language level, but sure, we can do that in the interim.

make async_generator_anext and async_generator_athrow real inspect.iscoroutines that support inspect.getcoroutinestate

How do you propose to fix this on the library level?

I don't think it can be it would need to be fixed in Objects/genobject.c https://bugs.python.org/issue44928

tasks created as part of asyncio.runners._cancel_all_tasks are aborted
tasks created as part of loop.shutdown_async_gens are aborted

Can we just outright raise an exception if one tries to create a task at that point?

yeah that would be good too

cancelling await stream.drain() breaks a protocol for other users

Not sure what the suggestion is here – need more details.

Yeah it's pretty complex problem, related to https://bugs.python.org/issue44428 I'm starting a more thorough writeup

[agronholm]

no - it's two slightly different aspects of trio cancellation

Ok, can you clarify it a little bit for me?

[graingert]

no - it's two slightly different aspects of trio cancellation

Ok, can you clarify it a little bit for me?

trio cancellation is: every time a cancelled task reaches a checkpoint it raises CancelledError. So that's two parts the "every time" and the "reaches a checkpoint". anyio has to work around asyncio in a few ways to achieve this: by cancelling eligible tasks every event loop cycle, and checking at task.get_coro() is in the correct state for cancellation eg (modified from the docs):

import asyncio

async def cancel_me():
    print('cancel_me(): before sleep')

    try:
        # Wait for 1 hour
        await asyncio.sleep(3600)
    except asyncio.CancelledError:
        print('cancel_me(): cancel sleep')
        raise
    finally:
        print('cancel_me(): after sleep')

async def main():
    # Create a "cancel_me" Task
    task = asyncio.create_task(cancel_me())

    # Wait for 1 second
    # await asyncio.sleep(1)  # commented out

    task.cancel()
    try:
        await task
    except asyncio.CancelledError:
        print("main(): cancel_me is cancelled now")

asyncio.run(main())

# Expected output:
#
#     cancel_me(): before sleep
#     cancel_me(): cancel sleep
#     cancel_me(): after sleep
#     main(): cancel_me is cancelled now

actual output:

main(): cancel_me is cancelled now

[graingert]

here's the anyio equivalent:

import anyio

async def cancel_me(*, task_status):
    join = anyio.Event()
    try:
        with anyio.CancelScope() as scope:
            task_status.started((scope, join))
            print('cancel_me(): before sleep')

            try:
                # Wait for 1 hour
                await anyio.sleep(3600)
            except anyio.get_cancelled_exc_class():
                print('cancel_me(): cancel sleep')
                raise
            finally:
                print('cancel_me(): after sleep')
    finally:
        join.set()


async def main():
    async with anyio.create_task_group() as tg:
        # Create a "cancel_me" Task
        scope, join = await tg.start(cancel_me)

        # Wait for 1 second
        # await asyncio.sleep(1)

        scope.cancel()
        await join.wait()
        print("main(): cancel_me is cancelled now")

anyio.run(main)

# Expected output:
#
#     cancel_me(): before sleep
#     cancel_me(): cancel sleep
#     cancel_me(): after sleep
#     main(): cancel_me is cancelled now

[njsmith]

One way to think about it: in asyncio, tasks have an implicit checkpoint before the first time they're scheduled. So if you create a task and then immediately cancel it, it never runs at all. Vs in Trio, once a task has been created, it can't be cancelled until it has started executing and reaches its first checkpoint.

[agronholm]

As a language improvement, providing a low level interface for overlapped I/O on Windows would be fantastic. There is such a module (_overlapped) but it doesn't have a public API.

[graingert]

yeah I'd love to kill twisted-iocpsupport

[agronholm]

Also, do we need to introduce new primitives beyond Future? Would there be any benefit from doing that?

[belm0]

cancel scopes → won't do

This is also in 3.11, correct?

[agronholm]

Nope.