On 7/18/22 19:20, Paolo Bonzini wrote:
On 7/14/22 17:13, Hanna Reitz wrote:
that we want to run before the others but still only when invoking
finalize/commit/abort.
I don’t understand this yet (but perhaps it’ll become clearer with the
following patches); doesn’t the new function do the opposite? I.e., basically
add some clean-up that’s only used after everything else?
I agree about the commit message being incorrect, but is there any reason why
transactions work LIFO by default? Is there anything that requires that
behavior?
Yes. On abort() we want to rollback actions in reverse order. When we create
_abort() part of some action we assume that current graph state is exactly the
same like it was after _prepare() call, otherwise it just will not work. That
means that all actions called _after_ action X, are already rolled-back when we
call X_abort().
And keeping that in mind I'm afraid of implementing a possibility to break this
order..
Note also, that in block transaction API, most of the action is usually done in
_prepare(), so that next action in transaction can rely on result of previous
action.
--
Best regards,
Vladimir
