CC @godlygeek

Sorry to be a pain here - but isn't there still a race here?

When sys.remote_exec() is called, in sys_remote_exec_unicode_path it is checked that the file exists and is readable. Then via send_exec_to_proc_handle we more or less just pass the path name and schedule it to be executed in the ceval loop in the remote process.

At least in a debug session I could verify, that the sending process gets back control (i.e. sys.remote_exec returns) before the file is read in the remote process. Still sitting on a debug breakpoint in

I could delete the file, before the remote process was able to read it.

It's similar to the other issue: like there, the sending process got control back before the remote process was done with the file. It just so happened, that it took so long to "free the file handle", that the sending process couldn't delete it (on Windows).

Here, the race is just earlier.

Sitll not a big issue IMHO: like already discussed in the other thread, in remote execution scenarious always the sending process should be the one to care about deleting of the script. And in there it can ask for an ACK back from the remote process ...

the sending process should be the one to care about deleting of the script. And in there it can ask for an ACK back from the remote process ...

Right, and that's exactly the thing that wasn't possible before this PR, but is possible now. The goal of this PR isn't to make it so that the caller can delete the script as soon as sys.remote_exec returns - you're correct that they still can't, because the script will be executed asynchronously. The goal of this PR is to make it so that the caller can delete the script once it sees that the script has been run.

In remote PDB, the caller correctly waits until the remote process executes the script and connects to its server before deleting the temp file, but that still wasn't good enough, because (on Windows) the file was locked by the remote until some time after the injected script had completely finished executing, and there was no way for the caller to know when the file became unlocked. After this PR, the caller only has to wait for some observable side effect of the script that was injected (in remote PDB's case it's the remote process connecting to the caller's socket) to know that the file can now be removed. This is how it was always meant to behave, and how it always did behave on POSIX OS's (where opening a file for reading doesn't prevent it from being deleted).

Great! Maybe a short summary should go into #132638?