Further mod on msvc config cache locking

[mwichmann]

In the first iteration, we took a read lock in the read case. A fail was observed where the reader took a json decode error, and then tried to remove the cachefile in case it's really corrupt. That failed as the file was "busy" - on Windows removing is essentially writing the file - so take a write lock here too.

This is a tweak to an internal detail that is not yet in an SCons release, so no further changes to CHANGES/RELEASE; no doc impacts. We don't have a test that can force this case, waiting for CI runs for more info.

Contributor Checklist:

• I have created a new test or updated the unit tests to cover the new/changed functionality.
• I have updated CHANGES.txt (and read the README.rst)
• I have updated the appropriate documentation

[jcbrill]

When the file lock times-out, an SConsLockFailure exception is raised.

The SConsLockFailure is not handled in either the vc.py read_script_env_cache method (read cache) or the write_script_env_cache method (write cache).

I'm not sure the run should terminate if the lock can't be acquired. In both cases, it might be better to issue a warning and proceed without the cache.

An abnormal termination of scons can also orphan the lock file (i.e., created but not deleted) which creates problems for future runs (i.e., always time-out).

[mwichmann]

I'm a little worried if it's that slow that the lock times out, but yes. no effort yet to handle that case.

[jcbrill]

Ran into it this morning which was likely explained by a confluence of events that do not represent real world usage:

• scons tests launched in a vwmare workstation from a vm network mapped drive folder on the host
• the vm files themselves are located on an external usb 3.2(?) drive
• anti-virus not disabled on the host pc or in the virtual pc
• launched test after logging in to vm windows which apparently detected available updates and begin downloading

Probably hard to find a slower configuration. Unfortunately, the local tests pretty much all failed. After vm updated and restarted all was well again.

An orphaned lock file will always cause a run failure.

[mwichmann]

We can certainly add protocol to try to detect an orphaned lock file... I think the ninja daemon setup has something like this by using the psutil package. However, I'd like to avoid going down that route until it's more firmly established that ew need to.