search

sarbian / ModuleManager

176 stars 96 forks source link

Added , FileShare.ReadWrite to the File.Open, to allow MM to read files #180

Closed linuxgurugamer closed 1 year ago

linuxgurugamer commented 1 year ago

which are already opened by KSP

This seems to be a problem on extremely fast computers, I ran into this on my new system, this patch eliminated the exceptions

Lisias commented 1 year ago

The real issue if that Module Manager is being instantiated twice (or even more). If only one copy of ModuleManager would be in execution, the situation in which it would try to compute the SHA for a given file in different threads would just not happen.

Having multiple Module Managers running at the same time on the rig is terrible, with some patches ending up being corrupted (by some reason, the Localization ones are specially prone to the problem).

I had said before, and I will say it again: there must be one ONE Module Manager running in memory, and without solving this problem, people will still be screwed by bad patching happening randomly across the system.

Once you secure only one ModuleManager running at a given time, you don't need to scramble patching every single place where code that was meant to run solo subtly is facing concurrency with itself.

(also on Forum)

linuxgurugamer commented 1 year ago

Please don't assume I'm an idiot.

There is only one copy of MM in the install. While I can't be positive, I suspect it may be the game itself which is keeping the file open; I tested this extensively, and copied an entire install from one computer where this doesn't happen onto a new computer (much faster) where it does happen.

sarbian commented 1 year ago

Regardless of the source of the issue, the patch makes sense. Another process could access the dll block and the reading.

linuxgurugamer commented 1 year ago

Thanks

Lisias commented 1 year ago

For the sake of completude: benchmarks executed on MacOS on spinning platers and APFS, and on Windows 10 using M2 and NTFS, revealed that opening files using FileShare.Read is sensibly faster than not using FileShare, with FileShare.ReadWrite being just a little tad slower then .Read.

So this is the way to go anyway, no matter the problem it mitigates.

My apologies and my thanks to LGG, some interesting insights came from this ordeal.