People shy away from this conclusion because doing everything both ways is quite hard and requires fancier abstractions to make nice than people are familiar with.
That's really is a simple and intuitive summary. Thank you for that insight!
http://reactivex.io/documentation/operators/backpressure.htm... describes ReactiveX's approach to the problem in great detail. To quote the section that essentially reaches the same conclusion as the grandparent post pointing out how "forks" (using the same pull-style data source twice) inherently require buffering/materialization or sampling:
> When a cold Observable is multicast (when it is converted into a connectable Observable and its Connect method is called), it effectively becomes hot and for the purposes of backpressure and flow-control it should be treated as a hot Observable. Cold Observables are ideal for the reactive pull model of backpressure implemented by some implementations of ReactiveX (which is described elsewhere). Hot Observables typically do not cope well with a reactive pull model, and are better candidates for other flow control strategies, such as the use of the operators described on this page, or operators like Buffer, Sample, Debounce, or Window.
There are great visuals if you expand the RxJS examples in the link above.
I feel like there's some wisdom here, but I don't think I grocked it
With joins, pushing only works if both sides push at the same time.
In general, joins work by a push on one side triggering a pull on the other side, and then both are combined.
For forks there should be some subscribe mechanism to turn pulls into pushes that can cheaply fan out to all subscribers.
(Side note, the mitigations ought to be completely symmetric. This is a sign there is more to the problem that I am missing.)
“Trigger” is not necessarily the relationship, between build and probe sides though it could be. The DAG paths that produce/push the probe can be triggered by the completion of the build. “Happens after” is more strictly apt.