Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ENH creating a memmaping_reusable_executor #286

Open
tomMoral opened this issue Feb 16, 2021 · 1 comment
Open

ENH creating a memmaping_reusable_executor #286

tomMoral opened this issue Feb 16, 2021 · 1 comment

Comments

@tomMoral
Copy link
Collaborator

Some people would like to benefit from joblib memmaping serialization while still retainning the flexibility of asynchronous computations offered by the concurrent.futures API. This issue intend to keep track of ideas for this feature.

We could expose a memmaping_reusable_executor that would use the serialization from joblib with the classical API. This would require some tweaking to correctly keep track of the memmap files. Talking with @pierreglaser IRL, he proposed the following strategy to keep track of memmap:

  • One could add references to memmaps in each future, releasing it only once a future is completed.
  • Never return memmapped objects.

This way, memmaps are only created when sending tasks to the pool of workers and once the futures that depends on it are done, no other process should require them to run.

@jakirkham
Copy link

Building off the discussion in issue ( joblib/joblib#705 ), wonder if it would be worth using SharedMemoryManager from Python 3.8+. There's also a backport package for Python 3.6 & 3.7

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants