[C++] Let Futures support cancellation

[asfimport]

There should be a way for consumers of Futures to notify that they are not interested in the task at hand anymore. For some kinds of tasks this may allow cancelling the task in-flight (e.g. an IO task, or a task consisting of multiple steps).

Reporter: Antoine Pitrou / @pitrou
Assignee: Antoine Pitrou / @pitrou

Related issues:

• [C++] Use FnOnce for TaskGroup's tasks instead of std::function (supercedes)
• [R][C++] Allow cancelling long-running commands (is depended upon by)

PRs and other links:

• GitHub Pull Request #7179
• GitHub Pull Request #9528

_{Note: This issue was originally created as ARROW-8732. Please see the migration documentation for further details.}

[asfimport]

Antoine Pitrou / @pitrou:
cc @fsaintjacques for opinions.

[asfimport]

Antoine Pitrou / @pitrou:
Potentially interesting read:
https://link.springer.com/chapter/10.1007/978-1-4842-4398-5_15
This paper looks interesting as well, but it's not in free access:
https://www.researchgate.net/publication/290103663_Composable_parallelism_foundations_in_the_IntelR_threading_building_blocks_task_scheduler

[asfimport]

Antoine Pitrou / @pitrou:
C++20 stop_token:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0660r9.pdf

[asfimport]

Wes McKinney / @wesm:
Probably the in-process thread will have to be abandoned. At least then subsequent tasks in the queue are unblocked from executing (even if it leads to oversubscription temporarily)

[asfimport]

Antoine Pitrou / @pitrou:
Microsoft PPL cancellation_token:
https://docs.microsoft.com/en-us/cpp/parallel/concrt/cancellation-in-the-ppl?view=vs-2019

[asfimport]

Ben Kietzman / @bkietz:
I'm not sure I see how a StopToken is distinct from a Future<void> which the main thread can optionally MarkFinished and which workers can poll for completion (completion of the future indicates workers have been cancelled).

[asfimport]

Antoine Pitrou / @pitrou:
Well, it's a distinct concept at the very least. And futures are more complex internally because you can wait on several of them at once.
(also our futures currently don't have callbacks)

[asfimport]

Weston Pace / @westonpace:
In C# they have cancellation tokens separate from futures (tasks in C#).  The logic is that cancellation tokens could be used in a wide variety of situations.  Perhaps coroutines, perhaps synchronous blocking code, perhaps async/await where the Tasks are somewhat hidden.  By creating a separate cancellation token they can maintain a consistent capability regardless of what threading utilities are in use.

From an Arrow perspective, even if we are only using futures, we might not want to expose the futures API to the customer.  I think we probably will want to (it's would be beneficial to customers also writing asynchronous code) but cancellation tokens would allow us to choose not to.

Also, a lesser concern, but the user can create one cancellation token and use it across several arrow calls.  So if some end-user action triggers a number of Arrow operations, some in parallel and some in series, the application doesn't have to keep track of all those futures.

 

[asfimport]

Antoine Pitrou / @pitrou:
Issue resolved by pull request 9528
#9528