Removed unbounded member of FsLock #14
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
added 2 commits
August 17, 2017 19:57
We've known for some time that write_bounds could become unbounded. It turns out, in practice, it is. This makes the comment of "yikes, unbounded" even more amusing. The accumulation is very slow, 128 bytes every so often but it's enough. Just goes to show, you should never allow unbounded collections. Signed-off-by: Brian L. Troutwine <blt@postmates.com>
We still need write_bounds to control when the senders set the read index for the receiver they are bound to but we have no need to buffer them into a VecDeque. In fact, owing to the pushing into the front of the buffer and popping only from the back a single Option is sufficient. This removes the unbounded member of the fslock structure. Signed-off-by: Brian L. Troutwine <blt@postmates.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
These two commits resolve the issue of unbounded memory growth in cernan. It turns out every messages sent through Sender would cause 128 bytes to be pushed onto an unbounded VecDeque. In a previous life this VecDeque was used for proper coordination between the Senders and its Receiver but the optimization made in #5 broke this need. In doing so, we also broke the emptying of this deque.
This is now corrected and hopper will use a bounded amount of memory.