Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

async Task cancellation #88

Open
maxfischer2781 opened this issue Jan 16, 2020 · 1 comment
Open

async Task cancellation #88

maxfischer2781 opened this issue Jan 16, 2020 · 1 comment
Labels
API the way people interact with the framework enhancement New feature or request

Comments

@maxfischer2781
Copy link
Contributor

Short description of the feature
Cancelling a task currently a) allows the task to delay/ignore the cancellation and b) does not wait for completion. This means the cancelling task has to manually account for shutdown (e.g. MatterMiners/lapis#80).

Instead, we should offer an API that cancels a task and waits for completion. Notably, our internal, non-async API (Task.__close__) relies on prompt and successful termination.

Describe the solution you'd like
A public, asynchronous method for immediate shutdown. Roughly equivalent to:

class Task:
    ...

    async def terminate(self):
        self.__cancel__()
        await self.done

I'm still not 100% sure if we should use Coroutine.close(via .__close__) or add a cancellation (like .cancel currently does). close has guaranteed semantics, but allows no async action by the Task. A cancellation may be easier to handle in the activity, but requires a check for promptness.

@maxfischer2781 maxfischer2781 added enhancement New feature or request API the way people interact with the framework labels Jan 16, 2020
@maxfischer2781
Copy link
Contributor Author

For reference, asyncio is about to introduce Task groups and (slightly) changes cancellation semantics as a result. This adds cancellation as an actively tracked feature of tasks.

An asyncio Task is considered "being cancelled" once task.cancel() is called. Iff the task catches the cancel exception, the task still counts as "being cancelled" unless task.uncancel() is called.


It could be worthwhile to have the async cancellation work similarly:

  • .cancel() the task, but do not __close__() it
  • await that the task is .done or .uncancelled()
  • return whether the task is done?

I don't think promptness is something we should enforce, since it is difficult to define and detect.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
API the way people interact with the framework enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant