Franck Charras

Alright here is what I've been using for caching to RAM: https://github.com/joblib/joblib/pull/534

The previous script https://github.com/joblib/joblib/pull/534 seems to run as expected but I don't think the performance is great. Moreover the manager.dict() seems to fail with very large objects (maybe because of...

II think it looks like #588 when we started and before a number of important issues were raised: - issues with garbage collection - issues with concurrent calls - issue...

All the test passed on my local install, but the CI still also show some timeouts on other backends. Let's see if the memory test pass with 0.05 additional seconds...

Trying the memory test with 0.1 seconds, if it doesn't pass I'll just remove it. I think the role of garbage collection is really hard to account for, did you...

The last fail is different, it happens during the first `next(result)`. https://travis-ci.org/joblib/joblib/jobs/330553351#L2306 Why can we see in [this traceback](https://travis-ci.org/joblib/joblib/jobs/330553347#L2602) that joblib's `pool.py` is used (and in a deadlock) when `backend...

Apparently it was Travis killing our processes because of the `result = np.zeros(int(1e7))` was too much. It passes after setting it to `result = np.ones(int(5*1e5), dtype=bool)` which is still enough...

Thank you for the comments. Indeed there is some cleaning needed. > Also, with regards to the blocking on non-blocking mode, I think that both have their value. Typically, when...

Some thoughts about blocking / non blocking: this is a naïve draft API: ``` ... def __init__(self, n_jobs=1, backend=None, verbose=0, timeout=None, pre_dispatch='2 * n_jobs', batch_size='auto', temp_folder=None, max_nbytes='1M', mmap_mode='r', return_generator=False, lazy_dispatch=False,...

I've disabled on windows the patch for the multiprocessing backend that solved the deadlock, and now it's green (but it doesn't look very stable on travis). However it would be...