pepijnve commented on code in PR #23522:
URL: https://github.com/apache/datafusion/pull/23522#discussion_r3579621488
##########
datafusion/physical-plan/src/spill/spill_pool.rs:
##########
@@ -259,31 +254,35 @@ impl Drop for SpillPoolWriter {
return;
}
- // Finalize the current file when the last writer is dropped
- if let Some(current_file) = shared.current_write_file.take() {
- // Release shared lock before locking file
+ // Finalize any spill files that were not finished yet
+
+ if !shared.current_write_files.is_empty() {
+ // Copy and clear `current_write_files` so we can release shared
lock before locking files
+ let files = shared.current_write_files.clone();
+ shared.current_write_files.clear();
Review Comment:
> Do we really need to release shared lock before locking files
I'm not entirely sure. My assumption was that this was already carefully
tuned, so I didn't want to change the lock nesting. If I understood it
correctly, the intention is to avoid IO while the shared lock is held.
`InProgressSpilFile::finish` can do IO so the shared lock is released before
calling `finish`.
> Does it make sense to take file out from current_write_files consecutively
then we could avoid clone?
Indeed since we're clearing anyway we can just take. I'll make that change
right away.
--
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]
