That isn’t entirely accurate. The consumer simply communicates that it is ready to have a certain amount data pushed to it - it doesn’t actively pull data.
So the difference is:
- In a pull scenario the client can be blocked if no data is available - i.e. it isn’t going to get anything else done. This is more important for a
GenServerwhich is a “client” than and for example aGenStageconsumer (which has one extremely narrowly defined responsibility anyway). - In an unconstrained push scenario a client process can be overwhelmed with data being pushed to it, which usually leads to the process mailbox growing which will have undesirable side effects.
- This is why
GenStageuses “push with backpressure”, i.e. consumers are never blocked nor are they overwhelmed as the producer is supposed to limit the flow through theGenStagepipeline.
So in my mind “pulling” always expresses the “risk” of being blocked.
It aways helps to know when process execution will be blocked given that code is strictly sequential inside any single process. There is nothing inherently “bad” about a process being blocked because its capability could be highly focused and there could be absolutely nothing else for it to do when it is blocked. But in certain capacities some GenServer based processes cannot afford to be blocked to function well, so that they are forced to “out source” any “blocking activities” to other secondary processes (GenServer docs: "handle_cast ... should be used sparingly" Why?).
In environments (without lightweight processes) that rely on heavyweight threads push based streams like ReactiveX are much more common.
Inside a process, data is pushed by calling a function, between processes data is pushed by casting a message from producer to consumer (call being used to acknowledge receipt of data by the consumer).
