Re: [RFC PATCH 2/8] transactions: add tran_add_back

[Vladimir Sementsov-Ogievskiy]

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