Attempt at adding debugging to delete-by-compiler to test https://git…

[MasterDuke17]

…hub.com/MoarVM/MoarVM/pull/1780

[MasterDuke17]

@ugexe so it looks like the outermost rmdir is failing? Which must mean the inner one is "succeeding", but something is left behind.

[MasterDuke17]

Ah ha, the ‘6B’ subdirectory is failing to be deleted, but then can’t be listed. Maybe it is just the usual Windows terribleness and we just need to add a delay and/or retry,

[ugexe]

Hmm, I think retrying is only needed for renaming. What I suspect is that since it is iterating over .dir that the directory handle for the e.g. ‘6B’ subdirectory is still open when we try to rmdir it. Maybe we should try to make the calls to .dir not lazy so that (presumably) the directory handle gets closed by the time we try to rmdir it.

edit: actually looking at the loops again I don't know why the handle would be left open since we are indeed done iterating over it when we try to delete it. Perhaps that suggests something in the libuv changes is leaving a handle open though.

[MasterDuke17]

Or maybe explicitly open the handle before and close after?Sent from my iPhoneOn Dec 2, 2023, at 10:42 AM, Nick Logan ***@***.***> wrote: Hmm, I think retrying is only needed for renaming. What I suspect is that since it is iterating over .dir that the directory handle for the e.g. ‘6B’ subdirectory is still open when we try to rmdir it. Maybe we should try to make the calls to .dir not lazy so that (presumably) the directory handle gets closed by the time we try to rmdir it. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>

[ugexe]

Actually I overlooked the can't be listed part. I'm not sure what that could mean actually...

[ugexe]

It looks like the sleeps work. Why would this start happening when using libuv though... 🤔

[ugexe]

https://nodejs.org/api/fs.html#fs_fs_rmdirsync_path_options shows they have a maxRetries option, although it defaults to 0 so I'm not sure if that is to avoid a similar issue or not

[ugexe]

https://github.com/nodejs/node/blob/78855fdefee77ea13df9fa1887dc650b849a4f6d/lib/internal/fs/rimraf.js#L243 suggests they do retry at least once

[MasterDuke17]

I don’t know whether we should retry at the lower level, i.e., MoarVM, or at the higher level, i.e., Rakudo?Sent from my iPhoneOn Dec 2, 2023, at 12:44 PM, Nick Logan ***@***.***> wrote: https://github.com/nodejs/node/blob/78855fdefee77ea13df9fa1887dc650b849a4f6d/lib/internal/fs/rimraf.js#L243 suggests they do retry at least once —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>

[ugexe]

Hard to say. One issue with putting it in Rakudo is we don't have a good way of determining if the error was e.g.ENOENT or ENOTDIR to determine which errors we should actually retry. I also wonder what the JVM does... if it also does its own IO retry stuff automatically that also probably suggests it should occur in MoarVM. However, if we ever wanted to provide max-retries and/or retry-delay options to all users (similar to what nodejs does) then it feels like we'd want it in Rakudo. I suspect the easiest way to get the most immediate benefit would be implementing the retry in MoarVM only on Windows.

[MasterDuke17]

I agree re starting with MoarVM on Windows. I guess I’ll add that to the MoarVM PR. If the problem crops up on other platforms we can consider moving the solution up to Rakudo.Sent from my iPhoneOn Dec 2, 2023, at 4:59 PM, Nick Logan ***@***.***> wrote: Hard to say. One issue with putting it in Rakudo is we don't have a good way of determining if the error was e.g.ENOENT or ENOTDIR to determine which errors we should actually retry. I also wonder what the JVM does... if it also does its own IO retry stuff automatically that also probably suggests it should occur in MoarVM. However, if we ever wanted to provide max-retries and/or retry-delay options to all users (similar to what nodejs does) then it feels like we'd want it in Rakudo. I suspect the easiest way to get the most immediate benefit would be implementing the retry in MoarVM only on Windows. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>