You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Support: use Windows 10 RS1+ API if possible to make moves more atomic
This addresses a small window of in-atomicity in the rename support for
Windows. If the rename API is stressed sufficiently, it can run afoul of
the small window of opportunity where the destination file will not
exist. In Swift, this causes the `LockFileManager` to improperly handle
file locking for module compilation resulting in spurious failures as
the file file is failed to be read after writing due to multiple
processes overwriting the file and exposing the window constantly to the
scheduled process when building with `-num-threads` > 1 for the Swift
driver.
The implementation of `llvm::sys::fs::rename` was changed in SVN r315079
(80e31f1) which even explicitly
identifies the issue:
~~~
This implementation is still not fully POSIX. Specifically in the case
where the destination file is open at the point when rename is called,
there will be a short interval of time during which the destination
file will not exist. It isn't clear whether it is possible to avoid
this using the Windows API.
~~~
Special thanks to Ben Barham for the discussions and help with analyzing
logging to track down this issue!
This API was introduced with Windows 10 RS1, and although there are LTSC
contracts that allow older versions to be supported still, the
mainstream support system has declared this release to be obsoleted. We
attempt to use the new API, and if we are unable to do so, fallback to
the old API. This allows us to maintain compatibility with older
releases.
0 commit comments