Implement watchlist cache and runtime cache #109
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
A watchlist cache is implemented. The watchlist is a list of immature timestamp files that should be upgraded at a later time. When a file is timestamped, its file path is added to the watchlist. The file is removed from the watchlis tonce it has been successfully pgraded. Immature timestamps no longer immediately exits the program with error, and instead an error is printed to stderr followed by a continuance of the program until the very end when the program exits with exit(1). A runtime cache is implemented. It is based on the premise that it is unlikely that a timestamp will be upgraded in the time that it takes to run the whole command, so the calendar servers will only be checked once per each new commitment. This is particularly useful for bulk upgrading of timestamps. If "immediate exit" was still implemented, this would not be possible. Without a runtime cache, checking each timestamp against each calendar server-- even with the same root commitment-- would be unbearably slow.
petertodd
requested changes
Aug 13, 2020
Co-authored-by: Peter Todd <[email protected]>
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.
Overview
Sometimes I forget to upgrade my timestamps, and I'd like to keep them upgraded. Instead of searching my filesystem for all immature timestamps, why not track them with the ots cache?
Various other improvements are included, as described below.
Note that it may be prudent to refactor the
upgradewatchlistcommand to be responsible for removing items from the watchlist, instead of theupgradecommand. Doing this in theupgradecommand might be very slow when the watchlist is enormous, which would make for a bad user experience when the user is only trying to upgrade a single timestamp. However, it is not clear why a user would prefer to upgrade a single timestamp and not all timestamps anyway...Commit message
A watchlist cache is implemented. The watchlist is a list of immature timestamp files that should be upgraded at a later time. When a file is timestamped, its file path is added to the watchlist. The file is removed from the watchlist once it has been successfully upgraded.
Immature timestamps no longer immediately cause exit of the program, and instead an error is sent to stderr followed by a continuance of the program until the very end when the program exits with exit(1).
A runtime cache is implemented. It is based on the premise that it is unlikely that a timestamp will be upgraded in the time that it takes to run the whole command, so the calendar servers will only be checked once per each new commitment. This is particularly useful for bulk upgrading of timestamps. If "immediate exit" was still implemented, this would not be possible. Without a runtime cache, checking each timestamp against each calendar server-- even with the same root commitment-- would be unbearably slow.