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

Handle parallel fetches correctly #14

Merged
merged 4 commits into from
Jun 14, 2021
Merged

Handle parallel fetches correctly #14

merged 4 commits into from
Jun 14, 2021

Conversation

magik6k
Copy link
Contributor

@magik6k magik6k commented Jun 11, 2021

Previously running 2 parallel paramfetch instances would result in corrupted parameter files, this PR adds an fs lock which should guard against that.

If we fail to acquire the lock, we'll wait for some time, then we'll re-check the file, and retry acquiring the lock if the file still isn't fetched

@magik6k magik6k requested a review from arajasek June 11, 2021 12:15
Copy link
Contributor

@arajasek arajasek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like it should work, but I would worry that it's somewhat risky / error-prone

}()
if lockfail {
// we've managed to get the lock, but we need to re-check file contents - maybe it's fetched now
ft.maybeFetchAsync(ctx, name, info)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this recursive call really better than just calling checkFile here and falling through to doFetch as needed?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not really recursive as maybeFetchAsync runs this in a goroutine.

We're just calling maybeFetchAsync because:

  • We don't want to be hashing files with those locks (want to do that in parallel, locks only for writing)
  • Given the above, we'd want to drop those locks before calling checkFile
  • After calling checkFile we'd need to acquire locks again
  • So at that point we can just call maybeFetchAsync

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

Successfully merging this pull request may close these issues.

3 participants