[PEAK] Re: trellis.Set.discard
Phillip J. Eby
pje at telecommunity.com
Sat Oct 11 23:45:41 EDT 2008
At 02:13 AM 10/12/2008 +0300, Sergey Schetinin wrote:
> >> There's more. For task, maintain rule runs twice, then undo run for
> >> both times. So it not run-undo-run or even run-undo-run-undo it's
> >> run-run-undo-undo. For @atomically it also runs twice, but without
> >> undo. How the same rule manages to run twice without undo?
> >
> > Because the first run is inside type(CV).__call__ - it's an initializer
> > that's supposed to be treated as if its run happened in a *previous* recalc
> > - and it should never be undone.
>
>Oh, I see! This indeed seem like the right thing to do, but if the
>initialization sets some discrete cells shouldn't they reset by the
>time this call returns?
I think you're almost right about this. I say "almost" because you
can pass data into this initialization; so should that count as a
write? I'm rather torn because the main use case for making the
initialization special is to deal with Service objects, whose
instantiation cannot be undone. So, undoing their setup seems also wrong.
>This would also solve the futures issue, I
>believe.
Yes and no. I think it could still be made to mess things up. I
don't think the initialization aspect is crucial to setting up a
futures-based retry cause the partial rollback of a rule.
More information about the PEAK
mailing list