This is well-defined and easy to do with the new cancellation
implementation: the task just gets marked as being cancelled, and then
the next time it executes a blocking trap, the CancelledError is
raised.
Okay, so we can do it. But is it useful? Actually, yes. Here's the
situation where I ran into this: I have a "supervisor" whose job it is
to manage a set of child tasks. One of the operations the supervisor
exposes is a shutdown method, which tells the supervisor to stop
accepting new tasks and cancels all extant tasks. I tried having one
of the tasks that runs inside the supervisor call shutdown. This
is a perfectly sensible thing it do -- in fact, the whole idea here is
that you make the supervisor task the "main" task, and then run all
your code as sub-tasks under it. And that includes the code that
decides when its time to shut down your program. But, of course, this
means that this task ends up cancelling itself.
This is well-defined and easy to do with the new cancellation implementation: the task just gets marked as being cancelled, and then the next time it executes a blocking trap, the CancelledError is raised.
Okay, so we can do it. But is it useful? Actually, yes. Here's the situation where I ran into this: I have a "supervisor" whose job it is to manage a set of child tasks. One of the operations the supervisor exposes is a
shutdownmethod, which tells the supervisor to stop accepting new tasks and cancels all extant tasks. I tried having one of the tasks that runs inside the supervisor callshutdown. This is a perfectly sensible thing it do -- in fact, the whole idea here is that you make the supervisor task the "main" task, and then run all your code as sub-tasks under it. And that includes the code that decides when its time to shut down your program. But, of course, this means that this task ends up cancelling itself.