ZipAsArray --> Buffering Limit

[jesse...@gmail.com]

Hello,

with regards to the ZipAsArray method, the API mentions:

"Be careful not to have too much "drift" between streams. If one stream produces many more values than some other excessive buffering will occur inside the zipped observable."

I was wondering if there is a limit on the amount of events that will be buffered.
Or will Bacon.JS just keep buffering till you run out of memory?

Let's say i Zip 2 streams, one which sends events at a fast rate, and one that hardly sends any events at all.

The events from the faster stream will be buffered, will this buffer:

A. act as a Bounded Buffer, meaning that once the buffer is full, events from the fastest stream will simple be discarded?

B. act as an unbounded Buffer, meaning that it can contain (theoretically) an infinite number of events?


Regards,

Jesse

[raimohanska]

It would be B.

And no, I've never used zip in any actual application. I find that it's typically either combine* or sampledBy that'll do the trick. Do you have an actual application for zip?

[jesse...@gmail.com]

Op donderdag 4 december 2014 16:35:48 UTC+1 schreef raimohanska:

Thanks for the reply!

I use Bacon.JS for my implementation of a Flow-Based Programming system.
I use the ZipAsArray function to ensure that a component with multiple IN-ports only starts processing once every IN-port has data available.

Consider this simple graph made in my editor: http://oi59.tinypic.com/200u4as.jpg

Connections (purple) are implemented using Bacon.Bus.
The "ADD" component simply adds the 2 values which it receives. But in order to execute, it must ensure that there is data available on both ports. This is done using ZipAsArray.

If i would disconnect one of the 'Counter -> Add' connections, the Add component will halt its execution (as intended).

If i use combineAsArray instead, the Add component keeps processing, since it just keeps using the latest value that was send over the now disconnected stream.

There is probably a workaround for this too, or it may just be my lack of understanding of other functions. Anyway zipAsArray does the job just fine.

[raimohanska]

Well, it seems you've found a use case for zip :) Nice stuff! I pointed out the alternatives just because some people seem to confuse those combinators with each other.