Fixes #342 by handling error in object file race condition

[MatthewDaggitt]

No description provided.

[MatthewDaggitt]

To do: add spin + timeout on writing of the standard library file in the first place.

[MatthewDaggitt]

Okay so much for that idea. Windows apparently doesn't provide native support for atomic file operations. Going to try locking next.

[MatthewDaggitt]

@wenkokke suggests looking at https://hackage.haskell.org/package/base-4.18.0.0/docs/Control-Exception.html#v:bracket

[wenkokke]

Why is the CI not running the build-vehicle tests?

[wenkokke]

Why is the CI not running the build-vehicle tests?

Error when evaluating 'runs-on' for job 'build-vehicle'. .github/workflows/build-vehicle.yml (Line: 10, Col: 14): Unexpected type of value '', expected type: OneOf.

[wenkokke]

Should we worry about these test failures?

quantifierIn
      TypeCheck:                FAIL (0.24s)
        Contents of stderr differ:
        0a1
        > Declaration 'StdLib.forallIn' not found when looking up variable in context [ User.emptyList ] at Line 6, Columns 9-15
        
        
        Use -p '/simple-quantifierIn.TypeCheck/' to rerun this test only.
      Agda:                     OK (0.33s)
    windController
      TypeCheck:                FAIL (0.24s)
        Contents of stderr differ:
        0a1
        > Error at Line 4, Columns 20-26: The name 'Tensor' is not in scope
        
        
        Use -p '/windController.TypeCheck/' to rerun this test only.

They’re from the latest runs, any modification in this PR was already made.

Is it possible you’ve just made this failure less likely?

[wenkokke]

Okay so much for that idea. Windows apparently doesn't provide native support for atomic file operations. Going to try locking next.

Any sense implementing this with atomic filter operations on Linux and macOS anyway, since that would be the best way to go about it?

[wenkokke]

Okay so much for that idea. Windows apparently doesn't provide native support for atomic file operations. Going to try locking next.

Could we use atomic-file-ops? It uses System.Directory.renameFile which calls MoveFileW on Windows, which is atomic for moves within the same NTFS file system.

Or, circumventing the need for another library, we could do an atomic write by writing to a temporary file and then renaming it. (The only caveat is that on Windows you must make sure that the temporary file is on the same file system.) That should give us atomic writes.

Then the whole procedure for the standard library, and for object files in general, can be to check if the file already exists, and if it doesn’t, atomically write it. We might end up doing some extra work, but as long as the result is deterministic, that’s not a huge issue.

The only issue might be when we’re interleaving compilation of user files, when an older compilation (from before an edit) writes the object file after the newer compilation. But that’s a bridge we’ll cross later.

[MatthewDaggitt]

Should we worry about these test failures?
They’re from the latest runs, any modification in this PR was already made.

Yes, we should be worrying about them.

Is it possible you’ve just made this failure less likely?

I don't understand. I've tested it locally on my Linux install, and the locking is working. So it's not the locking primitives that are wrong, it's my understanding of the race conditions.

Could we use atomic-file-ops? It uses System.Directory.renameFile which calls MoveFileW on Windows, which is atomic for moves within the same NTFS file system.

I'm not sure it'll help, because I think it's my logic that's wrong not the locking itself.