I noticed that nodejs will retry certain IO actions on failure specifically to work around issues on Windows holding handles open slightly longer than one would expect. This type of behavior is currently used in Rakudo in CompUnit::PrecompilationRepository::FileSystem for renaming files, but some recent PRs show that it would also be useful for rmdir (specifically for delete-compiler-id).
The problem is to implement a retry mechanism efficiently requires only retrying on what we might consider as a retry-able error (see: https://github.com/nodejs/node/blob/78855fdefee77ea13df9fa1887dc650b849a4f6d/lib/internal/fs/rimraf.js#L233-L280). But we don't have a way to distinguish e.g. ENOENT and ENOTDIR when calling e.g. $path.IO.rmdir from other errors in Rakudo itself other than parsing the error message. We should therefore figure out how to throw typed exceptions for these type of IO errors (and maybe parsing the error message is fine for now), as well as how we should expose these errors to users (new X:: classes would be ideal, but an attribute on e.g. X::IO::Rmdir would be more backwards compatible).
ugexe
commented
11 months ago
I noticed that nodejs will retry certain IO actions on failure specifically to work around issues on Windows holding handles open slightly longer than one would expect. This type of behavior is currently used in Rakudo in
CompUnit::PrecompilationRepository::FileSystemfor renaming files, but some recent PRs show that it would also be useful forrmdir(specifically fordelete-compiler-id).The problem is to implement a retry mechanism efficiently requires only retrying on what we might consider as a retry-able error (see: https://github.com/nodejs/node/blob/78855fdefee77ea13df9fa1887dc650b849a4f6d/lib/internal/fs/rimraf.js#L233-L280). But we don't have a way to distinguish e.g.
ENOENTandENOTDIRwhen calling e.g.$path.IO.rmdirfrom other errors in Rakudo itself other than parsing the error message. We should therefore figure out how to throw typed exceptions for these type of IO errors (and maybe parsing the error message is fine for now), as well as how we should expose these errors to users (newX::classes would be ideal, but an attribute on e.g.X::IO::Rmdirwould be more backwards compatible).