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

take the pinlock when updating pins #5550

Merged
merged 2 commits into from
Oct 2, 2018
Merged

take the pinlock when updating pins #5550

merged 2 commits into from
Oct 2, 2018

Conversation

Stebalien
Copy link
Member

No description provided.

License: MIT
Signed-off-by: Steven Allen <[email protected]>
@Stebalien Stebalien requested a review from Kubuxu as a code owner October 2, 2018 21:36
@ghost ghost assigned Stebalien Oct 2, 2018
@ghost ghost added the status/in-progress In progress label Oct 2, 2018
@magik6k
Copy link
Member

magik6k commented Oct 2, 2018

The pin command doesn't use coreapi yet, so I'm not sure if we still want the previous PR, or to just switch pin command to CoreAPI (which should be quite simple)

@Stebalien
Copy link
Member Author

The pin command doesn't use coreapi yet, so I'm not sure if we still want the previous PR, or to just switch pin command to CoreAPI (which should be quite simple)

No but the pin update command does (as of your patch...).

@magik6k
Copy link
Member

magik6k commented Oct 2, 2018

Oh, right, that got merged with the resolver cleanup stuff..

@@ -67,6 +67,8 @@ func (api *PinAPI) Update(ctx context.Context, from coreiface.Path, to coreiface
return err
}

defer api.node.Blockstore.PinLock().Unlock()
Copy link
Member

Choose a reason for hiding this comment

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

Do we actually need this lock before resolving? (which can take a while in case of /ipns/ paths, blocking other pin operations)

Copy link
Member

Choose a reason for hiding this comment

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

(IIRC this is backed by RWLock, so not that bad of an issue but still)

Copy link
Member Author

Choose a reason for hiding this comment

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

No, but I was trying to match what we do in Pin. I thought was also concerned about the fact that we may download the first node and then throw it away but, on closer inspection, that's not a problem. We're keeping it in memory anyways.

I'll fix both of these.

License: MIT
Signed-off-by: Steven Allen <[email protected]>
@Stebalien Stebalien requested a review from magik6k October 2, 2018 22:42
@Stebalien Stebalien merged commit d8ed9ab into master Oct 2, 2018
@ghost ghost removed the status/in-progress In progress label Oct 2, 2018
@Stebalien Stebalien deleted the fix/coreapi-pin-lock branch October 2, 2018 23:05
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.

2 participants