[PEAK] Re: trellis.Set.discard

[Sergey Schetinin]

>> 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? This would also solve the futures issue, I
believe.


>> 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.

That's because in that case the maintain and _data are scheduled in a
different order. So by the time _data runs maintain already ran and it
never needs to _retry. For tasks it runs second, so the _data has to
be rescheduled. The difference, I guess, is caused by scheduling
immediately and processing .writes for current_listener is / is not
None. So they end up on layers 2 and 3 for non-task and both on layer
4 for tasks



(PS. When I said `.added` in previous email I should have been `.to_add.`)