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

The add command's addAllAndPin function doesn't hold the pin lock #4561

Closed
Stebalien opened this issue Jan 8, 2018 · 8 comments · Fixed by #5506
Closed

The add command's addAllAndPin function doesn't hold the pin lock #4561

Stebalien opened this issue Jan 8, 2018 · 8 comments · Fixed by #5506

Comments

@Stebalien
Copy link
Member

While the file adder does hold the pin lock while adding a single file, the outer addAllAndPin function doesn't. This means that we can GC between adding and pinning.

@schomatis
Copy link
Contributor

@Stebalien Is someone working on this? I'm interested to learn more about the locking system while adding/pinning, as it's something I stumbled upon while working on #4650.

@Stebalien
Copy link
Member Author

Nope. All yours!

@schomatis
Copy link
Contributor

@Stebalien The exported AddFile function is just a wrapper for the internal addFile function while also holding the pin lock, and it's only used by addAllAndPin (in the ipfs add command). I think the logic of addAllAndPin should belong to the Adder and not to the ipfs add command (as the latter it's taking more responsability than it should about the add/pin logic). In this way addAllAndPin could directly use the addFile internal function while holding the pin lock all the way (including the call to PinRoot).

So the proposal would be:

  1. Move addAllAndPin inside the Adder (in coreunix), replacing the call to AddFile with addFile.

  2. Copy the pin lock logic from AddFile to addAllAndPin covering the calls to addFile and PinRoot.

  3. (optional) Eliminate AddFile which doesn't seem to be used anywhere outside addAllAndPin (and some tests).

As side note, I'm having trouble understanding the purpose of PinLock. Its name and comment seem to imply that someone who grabs that lock will use it to pin content, but the lock (that seems more related to the GC than the pin/add functionality) is commonly used just for add operations (that don't pin while holding this lock), e.g., AddFile, AddR and AddWrapped.

@Stebalien
Copy link
Member Author

Its name and comment seem to imply that someone who grabs that lock will use it to pin content, but the lock (that seems more related to the GC than the pin/add functionality)

You're right, it's a "don't GC" lock.


So, being able to add individual files is nice. We'll want to discuss this a bit before we get rid of that ability.

Ideally, anything added with the adder should be temporarily pinned until we call Finalize. At that point, we should remove the temporary pin add a real pin if adder.Pin was set. Unfortunately, we don't have a temporary pin system at the moment (although we desperately need one and it would allow us to get rid of the pin lock entirely).

@lgierth any opinions on this API?

@kjzz
Copy link
Contributor

kjzz commented Sep 15, 2018

hey @schomatis , are you still doing for this?if you do not finish, maybe i can help.because i am learn more about the add/pin.So i think maybe i can have a try.

@schomatis
Copy link
Contributor

Great! But we should first check with @Stebalien the status of this issue

@kjzz
Copy link
Contributor

kjzz commented Sep 17, 2018

Thx a lot @schomatis. If this issue is still pending,please ping me @Stebalien .

@kjzz
Copy link
Contributor

kjzz commented Sep 25, 2018

Hey @schomatis @Stebalien , i have create a pr #5506 about this issue . Could you help me review it?

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 a pull request may close this issue.

3 participants