ARROW-10182: [C++] Add basic continuation support to Future

[bkietz]

Adds Future<T>::Then(OnSuccess, OnFailure) which registers callbacks to be executed on completion of the future and yields a future which wraps the result of those callbacks; if a callback returns:

• void, Then() returns a Future<> which completes successully as soon as the callback runs.
• Status, Then() returns a Future<> which completes with the returned Status as soon as the callback runs.
• V or Result<V>, Then() returns a Future<V> which completes with whatever the callback returns.
• Future<V>, Then() returns a Future<V> which will be marked complete when the future returned by the callback completes (and will complete with the same result).

[github-actions]

https://issues.apache.org/jira/browse/ARROW-10182

[bkietz]

Added a benchmark to measure the cost of creating a Future in Executor::Submit instead of just using Executor::Spawn. Locally:

---------------------------------------------------------------------------------------------
Benchmark                                                      Time           CPU Iterations
---------------------------------------------------------------------------------------------
ThreadPoolSpawn/threads:4/task_cost:1000/real_time     201939036 ns  173389187 ns          6    967.19k items/s
ThreadPoolSpawn/threads:8/task_cost:1000/real_time     294998893 ns  264699658 ns          2   662.082k items/s
ThreadPoolSpawn/threads:4/task_cost:10000/real_time     36495616 ns    2546067 ns         19   535.194k items/s
ThreadPoolSpawn/threads:8/task_cost:10000/real_time     20151885 ns    3711374 ns         30   969.251k items/s
ThreadPoolSpawn/threads:4/task_cost:100000/real_time    36728060 ns     285424 ns         19   53.2046k items/s
ThreadPoolSpawn/threads:8/task_cost:100000/real_time    23104241 ns     415593 ns         29   84.5776k items/s
ThreadPoolSubmit/threads:4/task_cost:1000/real_time     20986410 ns   19332114 ns         33   465.377k items/s
ThreadPoolSubmit/threads:8/task_cost:1000/real_time     19378929 ns   18328342 ns         36    503.98k items/s
ThreadPoolSubmit/threads:4/task_cost:10000/real_time     2320937 ns     761124 ns        303   421.183k items/s
ThreadPoolSubmit/threads:8/task_cost:10000/real_time     1727973 ns    1442820 ns        393   565.714k items/s
ThreadPoolSubmit/threads:4/task_cost:100000/real_time    2085426 ns     112413 ns        329   47.2962k items/s
ThreadPoolSubmit/threads:8/task_cost:100000/real_time    1279387 ns     104251 ns        514   77.0938k items/s

This shows there is significant overhead for small tasks and pools with fewer threads. Follow up: https://issues.apache.org/jira/browse/ARROW-10625

[pitrou]

Thanks a lot, really nice.

[pitrou]

Nice. Do we want to use FnOnce in other places at some point? (perhaps open a JIRA?)

[bkietz]

Yes, I think it should replace std::function in thread_pool.h at least

[bkietz]

https://issues.apache.org/jira/browse/ARROW-10966

[pitrou]

... which is? Ideally, the user gets something "simple", such as Status or const Status&.

[westonpace]

Yes. They receive const Result<T>& or const Result<detail::Empty>&

[bkietz]

I think it's preferable to keep things as generic as possible, so the empty result is preferable to the plain Status

[pitrou]

This is changing the meaning of the tests, as now a pending future will pass this silently.

[westonpace]

Good catch. There should be an else block calling FAIL. I'll add that. The intent of this "if" wrapper is to prevent a pending future from deadlocking the test (which makes it difficult to debug). It absolutely should fail if the future is pending.

[bkietz]

CI failures are unrelated. Will merge

[westonpace]

LGTM