You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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 fromjoblib
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: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.
The text was updated successfully, but these errors were encountered: