Improve the execution of ahead streams

[harendra-kumar]

From #685 :

Let's take a simplified example:

[x1 ahead x2 ahead x3] ahead [y1 ahead y2 ahead y3] ahead [z1 ahead z2 ahead z3]

The implementation of ahead is such that it can execute x1, x2, y1, z1 in advance, but the rest of y stream i.e.y2, y3 and the > rest of z stream i.e. z2 and z3 won't be executed until the whole of x stream gets executed. Now, if let's say y1 or z1 took an > MVar that is required for x1, x2 or x3 to finish then we are into a deadlock. Also if the release of MVar depends on y2, y3 or > z2, z3 being executed then we can get into a deadlock.

Its implemented like that because it is simple to do so. But it is not an intuitive behavior. We can instead execute all the y streams before we go z. This will require a more complicated sequencing of actions though because until x streams are finished we won't know what sequence number to assign to y streams. So we will have start a new series of sequence numbers for y and have a list of different series.

Also another issue is that we do not know the size of x, so we really do not know when is the right time to start executing y. Because of this we may execute y much ahead in time and x may still be going for a long time.

It would be easier to implement this if we are flattening explicit stream of stream of actions e.g. t m (t m (m a)). In that case we can first generate a stream of actions and merge those streams in ahead manner to generate a single stream of actions and in the next stage we flatten that stream of actions in an ahead manner. That way we won't have the above mentioned issue of not knowing when the next stream starts.