pitrou commented on a change in pull request #9644:
URL: https://github.com/apache/arrow/pull/9644#discussion_r601471402
##########
File path: cpp/src/arrow/util/thread_pool.h
##########
@@ -104,15 +104,22 @@ class ARROW_EXPORT Executor {
template <typename T>
Future<T> Transfer(Future<T> future) {
auto transferred = Future<T>::Make();
- future.AddCallback([this, transferred](const Result<T>& result) mutable {
+ auto callback = [this, transferred](const Result<T>& result) mutable {
auto spawn_status = Spawn([transferred, result]() mutable {
transferred.MarkFinished(std::move(result));
});
if (!spawn_status.ok()) {
transferred.MarkFinished(spawn_status);
}
- });
- return transferred;
+ };
+ auto callback_factory = [&callback]() { return callback; };
+ if (future.TryAddCallback(callback_factory)) {
+ return transferred;
+ }
+ // If the future is already finished and we aren't going to force spawn a
thread
+ // then we don't need to add another layer of callback and can return the
original
+ // future
Review comment:
> `Transfer(finished_fut).AddCallback(...)` will run the callback
synchronously on the calling thread
Are you sure it does? `transferred.MarkFinished` is called on the thread
pool, so it would depend on whether it executes because the caller calls
`AddCallback`. In a way, it's even more underterministic than the current
version, though, so arguably worse.
That said, I do think it's a problem that this doesn't reliably transfer the
callbacks to the thread pool. Perhaps this isn't the right API after all:
instead of `ThreadPool::Transfer(future)`, do we instead want
`Future::AddCallback(Executor*, Callback&&)` and/or `Future::Then(Executor*,
Callback&&)`?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
