2011-07-05 24 views
14

Para lograr algo similar a las llamadas diferidas de los motores de aplicaciones de Google (es decir, se maneja la solicitud y luego se maneja la tarea diferida), experimenté un poco y se me ocurrió la solución para generar un hilo en el que mi llamada diferida es manejado.¿Está bien generar hilos en una aplicación wsgi?

Ahora estoy tratando de determinar si esto es una manera aceptable.

¿Es posible (de acuerdo con la especificación WSGI) que el proceso finalice por el servidor web después de que se maneje la solicitud real, pero antes de que todos los hilos se agoten?

(si es que hay una manera mejor, eso también sería bien)

+3

Es probable que desee tener algún tipo de disposición de cola de tareas + grupo de subprocesos, tanto para el rendimiento, como para evitar tener tantos subprocesos que se mueren de hambre entre sí. – Marcin

+0

@Marcin: un buen punto, cuando muestre que el enfoque del hilo es factible, implementaré tal infraestructura – keppla

+0

Me decepciona que aún no haya recibido ninguna respuesta. – Marcin

Respuesta

7

Fwiw, también tiene una lectura de:

http://code.google.com/p/modwsgi/wiki/RegisteringCleanupCode

El enganche de acciones para cerrar() de iterable es la única manera dentro del contexto de la propia especificación WSGI para hacer el trabajo diferido. Sin embargo, eso no está en un hilo separado y ocurriría dentro del contexto de la solicitud real, aunque después de que se supone que la respuesta ha sido devuelta al cliente. Por lo tanto, su acción diferida consumirá ese subproceso de solicitud hasta que el trabajo esté completo y para que el subproceso de solicitud no pueda manejar otras solicitudes hasta entonces.

En general, si utiliza subprocesos de fondo, no hay ninguna garantía de que ningún mecanismo de hospedaje espere hasta que los subprocesos de fondo se completen antes de cerrar el proceso. De hecho, ni siquiera se puede pensar en ningún mecanismo de despliegue estándar que espere. En realidad, no existe ninguna garantía de que los controladores atexit sean llamados al cierre del proceso, algo de lo que la documentación mencionada también se refiere brevemente.

13

WSGI no especifica el tiempo de vida de un proceso de aplicación (como la aplicación WSGI es un objeto invocable Python). Puede ejecutarlo de una manera completamente independiente del servidor web, en cuyo caso, solo usted controla la vida útil.

Tampoco hay nada en WSGI que le prohíba generar hilos, procesos o hacer lo que quiera.

+1

Gran terminología. –

Cuestiones relacionadas