OliLay commented on code in PR #43096:
URL: https://github.com/apache/arrow/pull/43096#discussion_r1705497677
##########
cpp/src/arrow/filesystem/azurefs.cc:
##########
@@ -1066,20 +1098,88 @@ class ObjectAppendStream final : public
io::OutputStream {
// flush. This also avoids some unhandled errors when flushing in the
destructor.
return Status::OK();
}
- return CommitBlockList(block_blob_client_, block_ids_,
commit_block_list_options_);
+
+ auto fut = FlushAsync();
+ RETURN_NOT_OK(fut.status());
+
+ return CommitBlockList();
+ }
+
+ Future<> FlushAsync() {
+ RETURN_NOT_OK(CheckClosed("flush"));
Review Comment:
I tried to unify the sync/async flush implementations, unfortunately that
did not work out due to lifetime issues in the async case. When an
`ObjectAppendStream` is deconstructed in RAII way, `Close()` (and therefore
`Flush()`) is called. If we call `FlushAsync()` in the close, we need to create
a `shared_ptr` from `this` (to ensure lifetime of `this` when the lambda is
actually called), but: we can not create a `shared_ptr` of `this` while it is
deconstructed. Hence in the `Close()` call we always must do a sync `Flush`
where we do not have to give these lifetime guarantees.
TLDR: `Flush()` and `FlushAsync()` impls are similar, but slightly different
and decoupled implementations.
--
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.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
