Windows: Iterative remove_dir_all
#96412
Conversation
This will allow better strategies for use of memory and File handles. However, fully taking advantage of that is left to future work.
rustbot
added
the
T-libs
|
Hey! It looks like you've submitted a new PR for the library teams! If this PR contains changes to any Examples of
|
|
r? @yaahc (rust-highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
It's possible that a file in the directory is pending deletion. In that case we might succeed after a few attempts.
|
r? rust-lang/libs |
JohnCSimon
added
S-waiting-on-review
|
Two months later, let's maybe reroll this. I'm quite keen to get this merged at some point because it's a perf improvement even without any follow up. r? rust-lang/libs |
| let mut dirlist = vec![f.duplicate()?]; | ||
|
|
||
| // FIXME: This is a hack so we can push to the dirlist vec after borrowing from it. | ||
| fn copy_handle(f: &File) -> mem::ManuallyDrop<File> { |
There was a problem hiding this comment.
This is gross but I don't see an easy alternative and it's commented with a fixme, so fine.
There was a problem hiding this comment.
Yeah, I aim to do some bigger changes which I'm hoping will fix this. But my initial attempt was way too big for one PR (it touched a lot of different places and the diff was awful) so this was the compromise solution. I hope it's very temporary.
| // Otherwise return the error. | ||
| Err(e) => return Err(e), | ||
| } | ||
| thread::yield_now(); |
There was a problem hiding this comment.
I do kind of wonder if it's worth sleeping a bit between these in order to maximize the chance that if it's a temporary failure, it goes away.
I guess in practice this might be good enough, though.
There was a problem hiding this comment.
Yeah, I've had some very mixed feedback about sleeping. Some people seemed quite horrified at the prospect. Though I'm uncertain if it was just the principle of the thing, In any case, I guess it would need some limit to help avoid some possible worst case scenario where we end up sleeping for each and every file. Depending on the version of Windows and the environment, the minimum sleep time may be as much as 16ms.
|
This makes sense to me, and while there are some nits I don't see great ways to fix them right now, and they don't really matter anyway. @bors r+ |
|
📌 Commit d579665 has been approved by |
bors
added
S-waiting-on-bors
Windows: Iterative `remove_dir_all` This will allow better strategies for use of memory and File handles. However, fully taking advantage of that is left to future work. Note to reviewer: It's probably best to view the `remove_dir_all_recursive` as a new function. The diff is not very helpful (imho).
Windows: Iterative `remove_dir_all` This will allow better strategies for use of memory and File handles. However, fully taking advantage of that is left to future work. Note to reviewer: It's probably best to view the `remove_dir_all_recursive` as a new function. The diff is not very helpful (imho).
…askrgr Rollup of 9 pull requests Successful merges: - rust-lang#96412 (Windows: Iterative `remove_dir_all`) - rust-lang#98126 (Mitigate MMIO stale data vulnerability) - rust-lang#98149 (Set relocation_model to Pic on emscripten target) - rust-lang#98194 (Leak pthread_{mutex,rwlock}_t if it's dropped while locked.) - rust-lang#98298 (Point to type parameter definition when not finding variant, method and associated item) - rust-lang#98311 (Reverse folder hierarchy) - rust-lang#98401 (Add tracking issues to `--extern` option docs.) - rust-lang#98429 (Use correct substs in enum discriminant cast) - rust-lang#98431 (Suggest defining variable as mutable on `&mut _` type mismatch in pats) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
This will allow better strategies for use of memory and File handles. However, fully taking advantage of that is left to future work.
Note to reviewer: It's probably best to view the
remove_dir_all_recursiveas a new function. The diff is not very helpful (imho).