statement-distribution: do not use OurViewChange

[ordian]

This would eliminate the data race between OurViewChange and ActiveLeaves signal and that's what most subsystem do to avoid this problem.

[eskimor]

I think we have to fix this the other way round - getting rid of ActiveLeavesUpdate. The view updates are handled in the network bridge and we are sharing a peer set for precisely the purpose of keeping our view in sync with peers. @rphmeier am I missing something?

[ordian]

I think we have to fix this the other way round - getting rid of ActiveLeavesUpdate. The view updates are handled in the network bridge and we are sharing a peer set for precisely the purpose of keeping our view in sync with peers. @rphmeier am I missing something?

OurViewChange message should be based exactly on ActiveLeavesUpdate signal, and most subsystems are using it, also signals are handled before messages, so this will ensure some ordering. But I agree we could equally use one and get rid of another.

[eskimor]

Ok, if we assume signals are handled first, then this is probably fine for activated - but deactivated could remove us a head with still messages in flight - no?

[ordian]

but deactivated could remove us a head with still messages in flight - no?

yes, but if a head is deactivated we don't want to handle these messages anyway
and this is also the case for OurViewChange, we use retain there, which is essentially the same

[rphmeier]

but deactivated could remove us a head with still messages in flight - no?

Yes. What we could do is keep around old heads for a small amount of time, but that's not urgent at all.