Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
feat:networking: (Synchronous) Consistent Broadcast for Filecoin EC #9858
feat:networking: (Synchronous) Consistent Broadcast for Filecoin EC #9858
Changes from all commits
c03ad9d
76031d7
1dadff3
d1a4f1d
72c80a3
0209052
749d133
8f48631
ebafb65
35f8abc
bf65418
894da94
91bd679
f2cc452
939e515
d574d04
3988cc9
c11ffa5
f59c246
8d260d7
90c2f9d
fa7e1ef
92f6d3e
df82a82
1a771e4
b7c297c
f24fc83
103d786
682ddf6
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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'm unsure about the thread-safety of this
blks
slice. We seem to be reading & modifying it somewhat unsafely, and while it's probably the case that the system won't ever race here, I'm...not sure.Can we reason through this a bit?
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 am using a
sync.Map
to prevent parallel read/writes and avoid requiring a specific lock for everyblksInfo
which may be harder to handle. I assumeblksInfo
as a single unit of data, and never read the data structure of blocks directly. Thus theload
,store
methods.That being said, I may have missed some subtle detail. Let me know if this makes sense.
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.
So my concern is that we load the
blksInfo
out of the sync.Map, but then read and modify theblks
field. I think if we have 2 calls toRcvBlock
, they both load the samebInfo
object (safely). After that, however, they're gonna be concurrently accessing theblks
slice, which I don't think is safe (eg. iterating over the blks field, while it's also being modified).I'm not 100% sure that I'm right, and even if so, I'm not sure whether simultaneous calls to
RcvBlock
are possible (need to 👀 more), but does that make sense?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.
Actually, looking at the code closer, we don't actually ever modify it. So we're probably okay here.
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 think we are OK on that, but I think you are right that there may be a race here as one routine may load the dict and another one may load it in parallel before the previous one has been able to store any potential changes.
I think this is fixed by moving this lock after the load statement in line 125. WDYT?
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.
@adlrocha I don't think that's sufficient. I think it needs to be held until no more writing happens, which is the end of the method (as currently written). Consider the following situation:
key
on line 125, drops the lockkey
on line 125, drops the lockstore
sblkACid
as the only entry corresponding tokey
on line 141, returnsblkBCid
as the only entry corresponding tokey
on line 141, returnsWaitForDelivery