-
Notifications
You must be signed in to change notification settings - Fork 11
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
Qubesdb with commit #52
Conversation
Co-Authored-By: hannes <hannes@mehnert.org>
Co-Authored-By: hannes <hannes@mehnert.org>
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.
got_new_commit
looks racy to me. If events are signalled for two keys in quick succession, we might only see one of them (and ignore it, if we're waiting for the other one).
I think it would also be safer to take the old value as an input, so we can return immediately if the caller is already out-of-date. Otherwise, the caller has to call values
immediately after starting the got_new_commit
operation, and it would be easy to get that wrong.
Co-Authored-By: linse <sschirme@gmail.com>
@talex5 we pushed an updated, (hopefully) race-free version for |
* Add new function got_new_commit to QubesDB. Co-Authored-By: hannes <hannes@mehnert.org>
CHANGES: - provide Qubes.DB.got_new_commit to wait for specific commit writes in QubesDB (mirage/mirage-qubes#52 @linse @hannesm)
Hello,
we extended the Qubes.DB module to provide two new functions:
The first resolves once the provided
key
is written to with an empty string (this is used in Qubes to signal a commit). It provides a partial map, where only keys withkey
as prefix are contained. The functionvalues
does the latter.The reason for these functions is to properly react to QubesDB updates (in our case, firewall updates), and not using a QubesDB where firewall rules are only partially written. This cannot be implemented with just the provided
after
.