[PEAK] Re: trellis.Set.discard

[Phillip J. Eby]

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.