Los documentos de joblib contienen la siguiente advertencia:

En Windows, es importante proteger el bucle principal de código para evitar el reaparición recurrente de subprocesos cuando se utiliza joblib.Parallel. En otras palabras, deberías escribir código como este:

import ....

def function1(...):
    ...

def function2(...):
    ...

... if __name__ == '__main__':
    # do stuff with imports and functions defined about
    ...

No debe ejecutarse ningún código fuera de los bloques "if __name__ ==‘ __main__ ’", solo importaciones y definiciones.

Inicialmente, supuse que esto era solo para evitar el caso ocasional en el que una función pasaba ajoblib.Parallel llamó al módulo de forma recursiva, lo que significaría que en general era una buena práctica pero a menudo innecesaria. Sin embargo, no tiene sentido para mí por qué esto solo sería un riesgo en Windows. Adicionalmente,esta respuesta parece indicar que si no se protegía el bucle principal, el código se ejecutó varias veces más lento de lo que hubiera sido por un problema no recursivo muy simple.

Por curiosidad, ejecuté el ejemplo súper simple de un bucle embarazosamente paralelo de los documentos de JobLib sin proteger el bucle principal en una caja de Windows. Mi terminal recibió spam con el siguiente error hasta que lo cerré:

ImportError: [joblib] Attempting to do parallel computing without protecting your import on a system that does not suppo
rt forking. To use parallel-computing in a script, you must protect you main loop using "if __name__ == '__main__'". Ple
ase see the joblib documentation on Parallel for more information

Mi pregunta es, ¿Qué pasa con la implementación de Windows de JobLib requiere que el bucle principal esté protegido en todos los casos?

Disculpas si esta es una pregunta súper básica. Soy nuevo en el mundo de la paralelización, por lo que es posible que me falten algunos conceptos básicos, pero no pude encontrar este tema discutido explícitamente en ningún lado.

Finalmente, quiero señalar que esto es puramente académico; Entiendo por qué esgeneralmente buena práctica escribir el código de esta manera y continuará haciéndolo independientemente de joblib.