> Maintenance and readability are high priority, and you won't find any custom
> multiprocessing code in scikit-learn at the moment,

Indeed. We do not want multiprocessing code in scikit-learn. The
corresponding code needs to be abstracted out and put in joblib.

Such code is tricky to get right -really-, this is one reason why we do
not want raw multiprocessing code in scikit-learn, but rather well-tested
helper functions. They and up hiding a lot of gory details that are
necessary to support the functionality in different settings and to fail
gracefully. Also, another reason is that we are not wed to
multiprocessing. Joblib has already support for threads and processes. It
will hopefully grow support for other backends.