-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
R4R: Don't acquire lock on read-only keybase #2555
Conversation
…llelization between gaiacli
Codecov Report
@@ Coverage Diff @@
## develop #2555 +/- ##
===========================================
- Coverage 60.32% 60.27% -0.06%
===========================================
Files 150 150
Lines 8613 8591 -22
===========================================
- Hits 5196 5178 -18
Misses 3069 3069
+ Partials 348 344 -4 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@@ -63,7 +63,7 @@ func runAddCmd(cmd *cobra.Command, args []string) error { | |||
return errMissingName() | |||
} | |||
name = args[0] | |||
kb, err = GetKeyBase() | |||
kb, err = GetKeyBaseWithWritePerm() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems that the old GetKeyBase
is now the one that returns a KeyBase in RO mode. May I suggest renaming GetKeyBaseWithWritePerm
to GetWriteKeyBase
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My initial approach was like yours, e.g. "oh, this is quite an API breakage - semantic changed radically". Though I must admit that I quite like the WithWritePerm
suffix. It makes clear that you are getting a dB in write mode.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree with @alessio here.
|
||
// GetKeyBaseWithWritePerm initialize a keybase based on the configuration with write permissions. | ||
func GetKeyBaseWithWritePerm() (keys.Keybase, error) { | ||
rootDir := viper.GetString(cli.HomeFlag) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Feel free to declare this out of scope of this PR, but it would be super nice to remove this function entirely and instead use GetKeyBaseFromDir
variants (probably renamed to remove the FromDir
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the API exposed here. It explicitly mentions the permissions you are getting when you open the database.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The point I was making was removing the viper global variable, in favor of always explicitly passing in the rootDir, not about the permission itself.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
++
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed, I guess it can be a separate PR though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ValarDragon I agree, let's do it in a separate PR, shall we?
Co-Authored-By: alessio <quadrispro@ubuntu.com>
Co-Authored-By: alessio <quadrispro@ubuntu.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
utACK -- thanks @alessio
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor comment.
@@ -426,6 +426,11 @@ func (kb dbKeybase) Update(name, oldpass string, getNewpass func() (string, erro | |||
} | |||
} | |||
|
|||
// CloseDB releases the lock and closes the storage backend. | |||
func (kb dbKeybase) CloseDB() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we call this (e.g. in the code) in places other than the testcase you added? Seems like maybe so...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah maybe
|
||
// GetKeyBaseWithWritePerm initialize a keybase based on the configuration with write permissions. | ||
func GetKeyBaseWithWritePerm() (keys.Keybase, error) { | ||
rootDir := viper.GetString(cli.HomeFlag) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed, I guess it can be a separate PR though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
utACK, let's split out calling Close()
and removing the Viper global usage to a second PR
Expose calls to acquire non-blocking read lock on LevelDB stores.
Change
GetKeyBase()
so that it opens stores in read-only mode by default.Add
GetKeyBaseWithWritePerm()
to acquire write locks on stores.Closes: #1255
docs/
)PENDING.md
with issue #Files changed
in the github PR explorerFor Admin Use: