Franck Charras

For the example, one could think of a media player, the processes download some files to the disk in parallel, and the main thread load and read them. The processes...

I don't know how the two tests fail on travis, it does not consistently fail and I can't reproduce it locally. Also, 7 out of 8 pipeline passed. Could it...

Still can't find the deadlock with `taskset -c 0 pytest ...` locally. [This issue on Travis](https://github.com/travis-ci/travis-ci/issues/4696) suggests that `mp.cpu_count()` that is used by joblib does not return the appropriate number...

I didnt change the PR and triggered the CI again, you can see that now the new unittests in the PR are green but the simple parallel test fails. But...

I've rebased on upstream master, let's see how the tests behave after https://github.com/joblib/joblib/pull/640

Added an example in the gallery after @GaelVaroquaux idea: highlight the memory gain when the generator is consumed faster than the output are returned by the tasks. The script has...

Woops, a few GB is still too much for circleci, decreasing the values until it passes... edit: all green, also the old timeout errors apparently are gone for good.

`memory_profile` is not a joblib dependency so I can't use the `@profile` decorator within this PR, so here's a better highlight of the memory gain seen [in the example](https://github.com/fcharras/joblib/blob/b171e111b495ec05cd2cd34d30c62b1112d5ee6b/examples/parallel_generator.py) with...

And that is interesting: when forcing garbage collection after the consumption of each element of the output generator, the memory footprint really remains constant at a low level: ``` from...

Thank you for the comments, I've pushed changes that should address it. @tomMoral @GaelVaroquaux about using or not `gc.collect`: > The two last posts show that the difference is surprisingly...