Es concurrent.futures una medicina de la GIL?

Estaba buscando esta nueva implementación, y uso Python 2.7, debo instalar esto , así que si lo uso, ¿olvidaré la palabra GIL en CPython?

No, concurrent.futures tiene casi nada que ver con la GIL.

Usar procesos en lugar de hilos es una medicina para la GIL. (Por supuesto, como todas las medicinas, tiene efectos secundarios. Pero funciona).

El módulo de futures solo le brinda una forma más sencilla de progtwigr y esperar en las tareas que mediante el uso de threading o multiprocessing directamente. Y tiene la ventaja adicional de que puede intercambiar entre un grupo de subprocesos y un grupo de procesos (y tal vez incluso un bucle greenlet, o algo loco que invente y construya) sin cambiar el código future . Por lo tanto, si no sabe si su código tendrá problemas de GIL, puede comstackrlo para usar subprocesos y luego cambiarlo para usar procesos con un cambio de una línea, lo cual es bastante bueno.

Pero, si usa ThreadPoolExecutor , tendrá exactamente los mismos problemas de GIL como si creara un grupo de subprocesos, una cola de tareas, etc. manualmente con threading y una queue . Si usa ProcessPoolExecutor , evitará los problemas de GIL de la misma manera (y con las mismas compensaciones) como si usara el multiprocessing manualmente.

Y el paquete PyPI es solo un backport simple del módulo concurrent.futures de 3.2 a 2.x (y 3.0-3.1). (No te da mágicamente el nuevo y mejorado 3.2 GIL, o el 3.3 GIL más mejorado, y mucho menos elimina el GIL).


Probablemente ni siquiera debería haber mencionado los cambios de GIL, porque esto parece que acaba de agregar confusión … pero ahora, déjame tratar de aclararlo, simplificando demasiado.

Si no tiene más que trabajo IO-bound, los subprocesos son una excelente manera de obtener la concurrencia, hasta un límite razonable. Y 3.3 hace que funcionen aún mejor, pero para la mayoría de los casos, 2.7 ya es lo suficientemente bueno y, en la mayoría de los casos donde no lo es, 3.3 todavía no es lo suficientemente bueno. Si desea manejar 10000 clientes simultáneos, va a querer usar un bucle de eventos (por ejemplo, twisted , tornado , gevent , tulip , etc.) en lugar de hilos.

Si tiene algún trabajo vinculado a la CPU, los subprocesos no ayudan a paralizar ese trabajo en absoluto. De hecho, empeoran las cosas. 3.3 hace que la penalización no sea tan grave, pero sigue siendo una penalización, y aún así no debes hacer esto nunca. Si desea paralelizar el trabajo de la CPU, debe usar procesos, no hilos. La única ventaja de 3.3 es que los futures son un poco más fáciles de usar que el multiprocessing y vienen incorporados en lugar de tener que instalarlos.

No quiero desalentarte de pasar a la versión 3.3, porque es una mejor implementación de un lenguaje mejor que la 2.7. Pero una mejor concurrencia no es una razón para moverse.