unwanted consequences of restricting concurrency using maxYields

[harendra-kumar]

For APIs that use only a few results from the stream we restrict concurrency to a maximum of those many threads (using maxYields internally). However, this may not be correct always, because the number of threads may not directly translate into number of results. For example, the following code effectively becomes serial, because take 1 restricts the number of threads to 1:

constraint p = if p then return () else S.nil

interleave :: WAsyncT IO (Word, Word)
interleave = do
    x <- S.enumerateFromTo 0 20
    y <- S.enumerateFromTo 0 20
    tid <- S.yieldM myThreadId
    S.yieldM $ putStrLn $ show tid ++ " " ++ show (x,y)
    constraint $ x == 20
    return (x, y)

main :: IO ()
main = do
    xs <- S.toList $ wAsyncly $ S.take 1 interleave
    print xs

Instead of restricting concurrency implicitly via operations like take we should give the control in the hands of the user, via maxBuffer etc. Maybe we can provide a configuration combinator to enable this behavior of take et al.