[PEAK] Re: trellis.Set.discard

Sergey Schetinin maluke at gmail.com
Sat Oct 11 18:06:03 EDT 2008


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?

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.

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.

And savepoints in "futures" do seem to be broken, but for things like
tasks and @modifiers can they even be fixed?



More information about the PEAK mailing list