WIP: implement cancellation and raw handles

[udoprog]

This is a WIP PR for implementing a simple form of cancellation, as mentioned here. Since work on structured concurrency is underway this might not be necessary, but I'm setting this up so that others can have a look and provide input.

While related to structured concurrency it does not replace it. It is only a low-level primitive necessary to perform some best-effort graceful shutdown (#1819) over spawned tasks.

Note that this does not allow for graceful termination of tasks spawned with spawn_blocking that are actively blocking, which includes most File operations.

Warning: Naming is provisional, and certain assumptions around task shutdown might not be correct since I'm still not super familiar with the task system.

Motivation

Support for some form of cancellation is necessary to support graceful termination . This doesn't replace structured concurrency, but should be considered more of an incremental step towards allowing application and library authors to support graceful termination of background tasks without adopting a different API.

Solution

Hooks into the existing task system, and extends completion polling with a variant which doesn't export the output value to support raw join handles. This allows us to cancel tasks (which are currently not being polled), and .await their termination. Hopefully providing their Output or a simple completion signal on a best-effort basis.

[carllerche]

Hey, sorry for the delay. I am finally getting to this and it is definitely something that I think we should move forward with. The structured concurrency strategy has been put on hold indefinitely as we don't have a way forward with it.

I suggested splitting out the RawJoinHandle part. I would suggest starting a discussion issue for that.

As far as I can tell, the actual cancellation bit is not too involved as it can leverage shutdown(). I would probably recommend naming it something a bit more forceful like abort()?

What do you think?

[carllerche]

I'm not necessarily against this, but could we decouple exposing RawJoinHandle as a public API from this PR? I would like to explore alternate solutions like providing a custom collection type.

[udoprog]

Rebased and renamed to abort for now.

How do you want me to hide this from the public API?

Completely remove it, make private with #[allow(unused)], or #[doc(hidden)]?

[carllerche]

Completely remove it in this PR. I would like to get abort landed. I don’t think a raw handle is the path forward. Lets discuss the use cases that motivated you that direction so we can figure out an option.

[udoprog]

Removed, thanks!

[carllerche]

Looks great 👍 thanks! Sorry for the delay.

[najamelan]

I have a question that I feel the documentation of this method should answer. Will the task be cancelled (read dropped) the next time it is polled? The next time the joinhandle get's polled? Does the joinhandle need to be awaited for it to be dropped or just the task polled?

Ok, sorry, that's 3 questions. You get the issue I think.

[udoprog]

@najamelan The task is de-scheduled and dropped in the background, regardless if you poll it or not. The JoinHandle only gives you access to the output, but has to my understanding no bearing on the state of the task. Other than whether it can discard the output of the task, which it would if the JoinHandle is dropped.

[najamelan]

Thanks for clarifying. What happens if the future is currently running? I know in futures (Abortable/RemoteHandle), the canceling happens in the poll method, so abort calls waker.wake() to reschedule it so it completes. Reading the docs in this PR I was kind of confused about the mechanics here.

[udoprog]

Thanks for clarifying. What happens if the future is currently running? I know in futures (Abortable/RemoteHandle), the canceling happens in the poll method, so abort calls waker.wake() to reschedule it so it completes. Reading the docs in this PR I was kind of confused about the mechanics here.

Just for clarity: a task associated with a future is either being polled (i.e. running), or it's parked. If a task is cancelled in the middle of a poll the scheduler will notice this when the poll returns, and regardless of whether it returns Poll::Ready(..) or Poll::Pending finalize the task. Which involves dropping it.