laskoviymishka commented on code in PR #2696:
URL: https://github.com/apache/iceberg-rust/pull/2696#discussion_r3480650837
##########
crates/iceberg/src/delete_file_index.rs:
##########
@@ -86,17 +86,21 @@ impl DeleteFileIndex {
data_file: &DataFile,
seq_num: Option<i64>,
) -> Vec<FileScanTaskDeleteFile> {
- let notifier = {
+ // Create the `Notified` while holding the read lock.
`notify_waiters()` stores no
Review Comment:
I think the comment describes the wrong mechanism, and since it's the only
explanation of why this is correct I'd want it tightened before merge.
The populator drops the write lock *before* it calls `notify_waiters()`
(over in the populate task), so holding this read lock doesn't actually block
the signal — a `notify_waiters()` can still fire the instant we drop the guard,
before we first poll the future. What saves us is narrower: tokio captures the
`notify_waiters_calls` counter when the `Notified` is constructed, so a
`notify_waiters()` that lands after construction bumps the counter and the
future resolves on the first poll. The read lock's real job is just to stop the
state flipping to `Populated` between the read and the construction.
Worth getting right because someone porting this to the other two sites will
reason from this comment — and the same wording would steer them toward a
borrowed `Notified<'_>` or a `notify_one` context where the logic doesn't hold.
Could we reword it around the counter-captured-at-construction guarantee?
--
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
