[PEAK] Re: trellis.Set.discard
Phillip J. Eby
pje at telecommunity.com
Sat Oct 11 18:37:26 EDT 2008
At 01:06 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.
>It appears that due to this code in run_rule:
>
> old = self.current_listener
> self.current_listener = listener
> try:
> [...]
> if old is not None:
> [...]
> else:
> if initialized:
> self.has_run[listener] = self.savepoint()
> [...]
>
>when we create CV instance in @atomically variant, there's no
>current_listener and when the Cell for maintain initializes it isn't
>recorded in has_run and when .v changes that allows it to be scheduled
>to run one more time without adding it to to_retry, and thus without
>rollback , which can't be right.
Actually, that part *is* right, or at least, is perfectly as
designed. The problem is that .future attributes can save a
savepoint that points back into the middle of the first execution.
>For task variant, the same code also works without adding the cell to
>has_run (but because of a different condition), so when the
>TaskCell.do_run schedules the dependent rules, it schedules the
>maintain rule without to_retry as well. I'm not sure yet, why the undo
>run in this case at all.
Yes, that's really the question: why is an undo happening in the
first place? That's the part that makes no sense to me.
Okay, so I put a trace in the place where retry occurs, and I see the
following:
.maintain --wrote--> .s.to_add --wasreadby--> .s._data
And since .s._data has apparently already run once, it has to be re-run.
What this doesn't explain is why this *doesn't* happen in the non-task case.
>And savepoints in "futures" do seem to be broken, but for things like
>tasks and @modifiers can they even be fixed?
I don't know. I also don't know if perhaps there's a problem here
with how "initializing" of rules is working.
More information about the PEAK
mailing list