Properly handle concurrent access to qubes.xml

[marmarek]

When two tools concurrently modify qubes.xml, one will "rollback" changes made by the other. Generally because each tool first load qubes.xml, do it's work, then (optionally) rewrite the whole file with new state. In core2 we have two locking methods - lock_db_for_reading and lock_db_for_writing - if one want to modify qubes.xml, he/she needs to take write (exclusive) lock.
Not sure how it should be done here. Maybe somehow similar (but using __init__() or load() parameter)?

[marmarek]

As a stopgap I'll add detection of such situation and raise an exception. So at least it will be obvious what happened...

[marmarek]

As a stopgap I'll add detection of such situation and raise an exception. So at least it will be obvious what happened...

[woju]

I'm working on such a schema: .__init__() will have additional argument lock, which when set to True will lock the file (with LOCK_EX) until .save() is executed. If loaded with lock=False, there will be .reload(), which again will have lock argument.

Attempt to .save() without locking first will be as in present situation, best-effort: will either succeed or fail when someone would have overwritten qubes.xml. Alternatively we can try to discourage developers from doing that by unconditionally failing, but it's probably bad idea, since the events would already be fired, so for existing code it would actually be worse than what is now.

There would be no equivalent for .lock_db_for_reading().

@marmarek #1901

[woju]

I'm working on such a schema: .__init__() will have additional argument lock, which when set to True will lock the file (with LOCK_EX) until .save() is executed. If loaded with lock=False, there will be .reload(), which again will have lock argument.

Attempt to .save() without locking first will be as in present situation, best-effort: will either succeed or fail when someone would have overwritten qubes.xml. Alternatively we can try to discourage developers from doing that by unconditionally failing, but it's probably bad idea, since the events would already be fired, so for existing code it would actually be worse than what is now.

There would be no equivalent for .lock_db_for_reading().

@marmarek #1901

[marmarek]

I think this is very good compromise between usability and complexity. 👍

[marmarek]

I think this is very good compromise between usability and complexity. 👍

[woju]

.reload() proved to be tricky. One can always instantiate new app object, if requred. So closing.

[woju]

.reload() proved to be tricky. One can always instantiate new app object, if requred. So closing.