Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Merged
merged 1 commit into from
May 15, 2023

Conversation

linuxgurugamer
Copy link
Contributor

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
Copy link

Lisias commented May 15, 2023

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
Copy link
Contributor Author

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 sarbian merged commit d4574b4 into sarbian:master May 15, 2023
@sarbian
Copy link
Owner

sarbian commented May 15, 2023

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

@linuxgurugamer
Copy link
Contributor Author

Thanks

@Lisias
Copy link

Lisias commented May 18, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants