You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, there is no way to communicate backpressure through the pipeline (i.e. the downstream component cannot keep up, so the upstream component waits with its processing).
For perfect reproducibility this feature is needed, however, making the pipeline fully deterministic (provided that all the components are deterministic as well).
It might also be handy at some point to have backpressure between certain compoents.
An ideal place to implement this would be the vision-lib, s.t. we can easily configure it through the stage applications. The backpressure itself could be exerted on the stage application by blocking the publish() call as long as the stream is "full".
Some rough implementation ideas:
Do not set the trimming MAXLEN parameter in xadd() in the sender, but rather have the receiver either xdel() or xtrim() the stream after having processed an entry and have the sender track the stream length, and block if the stream length is greater than a defined stream length limit
A simpler version could forego streams completely and use a single key with set() for data exchange
The text was updated successfully, but these errors were encountered:
Currently, there is no way to communicate backpressure through the pipeline (i.e. the downstream component cannot keep up, so the upstream component waits with its processing).
For perfect reproducibility this feature is needed, however, making the pipeline fully deterministic (provided that all the components are deterministic as well).
It might also be handy at some point to have backpressure between certain compoents.
An ideal place to implement this would be the vision-lib, s.t. we can easily configure it through the stage applications. The backpressure itself could be exerted on the stage application by blocking the
publish()
call as long as the stream is "full".Some rough implementation ideas:
MAXLEN
parameter inxadd()
in the sender, but rather have the receiver eitherxdel()
orxtrim()
the stream after having processed an entry and have the sender track the stream length, and block if the stream length is greater than a defined stream length limitset()
for data exchangeThe text was updated successfully, but these errors were encountered: