sdd commented on code in PR #982:
URL: https://github.com/apache/iceberg-rust/pull/982#discussion_r2094972806
##########
crates/iceberg/src/delete_file_index.rs:
##########
@@ -199,18 +218,22 @@ pub(crate) struct DeletesForDataFile<'a> {
state: Arc<RwLock<DeleteFileIndexState>>,
data_file: &'a DataFile,
seq_num: Option<i64>,
+ waker_set: Arc<WakerSet>,
}
impl Future for DeletesForDataFile<'_> {
type Output = Result<Vec<FileScanTaskDeleteFile>>;
- fn poll(self: Pin<&mut Self>, _cx: &mut Context<'_>) -> Poll<Self::Output>
{
+ fn poll(self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Self::Output> {
match self.state.try_read() {
Ok(guard) => match guard.deref() {
DeleteFileIndexState::Populated(idx) => Poll::Ready(Ok(
idx.get_deletes_for_data_file(self.data_file, self.seq_num)
)),
- _ => Poll::Pending,
+ _ => {
+ self.waker_set.insert(cx);
+ Poll::Pending
+ }
},
Err(err) => Poll::Ready(Err(Error::new(ErrorKind::Unexpected,
err.to_string()))),
}
Review Comment:
Hi @xxchan - thanks for the feedback. Good spot on the `WouldBlock` error,
I've updated accordingly. Regarding the `Future` vs `async fn`, I agree that
`async fn` has fewer sharp edges but conceptually in this case I think that
`Future` is a better fit. Since the `Future` required in this particular case
is not a particularly complex one I think it is justified. We're essentially
waiting on something to be ready before we proceed with its value which is
exactly the intended use case of a `Future`.
--
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: issues-unsubscr...@iceberg.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@iceberg.apache.org
For additional commands, e-mail: issues-h...@iceberg.apache.org
