Python: Separación del proceso de GUI del proceso de lógica central

Question

Estoy desarrollando un Python project para manejar simulaciones de computadora, y también estoy desarrollando una GUI para él. (La lógica del núcleo en sí no requiere una GUI.) El kit de herramientas de GUI que uso es wxPython, pero creo que mi pregunta es lo suficientemente general como para no depender de ello.

La manera en que la GUI actualmente funciona es que inicia el paquete de lógica central (llamado garlicsim) en el mismo proceso y el mismo hilo que la GUI. Esto funciona, pero entiendo que es un enfoque problemático, porque si la lógica central necesita hacer algunos cálculos difíciles, la GUI se bloqueará, lo cual considero inaceptable.

¿Qué debo hacer?

Escuché acerca de la opción de iniciar la lógica del núcleo en un proceso separado de la GUI. Esto suena interesante, pero tengo muchas preguntas sobre esto.

1. hacer yo utilizo el paquete o el paquete multiprocessingsubprocess para poner en marcha el nuevo proceso?
2. ¿Cómo puedo acceder fácilmente a los datos de simulación del proceso de GUI? Después de todo, se almacenará en el otro proceso. El usuario debería poder navegar fácilmente por la línea de tiempo de la simulación. ¿Cómo puede hacerse esto?

Answer 1

Puede encontrar algo de inspiración aquí: http://wiki.wxpython.org/LongRunningTasks, sin embargo, es para multiprocesamiento, no multiproceso.

La idea básica

• para multihilo: utilizar una cola de eventos para la comunicación entre la GUI y el hilo de procesamiento.
• para multiprocesamiento: puede utilizar el paquete de subproceso y utilizar stdin/stdout del proceso hijo para comunicarse con él. Para esto, necesitas una API de línea de comandos, pero al final te resultará útil, ya que puedes realizar pruebas unitarias independientes de la GUI.

Incluso puede conducir la comunicación de E/S a través de un zócalo, esto permitiría una fácil administración de la red de la simulación.

Editar: acabo de ver la nueva 2.6-multiprocesamiento paquete que usted ha mencionado. Parece una buena elección, podría usar colas para comunicarse entre procesos. Este es un acoplamiento más ajustado, puede elegir según sus necesidades.

Answer 2

Desafortunadamente, aunque tiene razón en que la elección de la GUI no afecta la respuesta, el mejor enfoque para este problema dependerá en gran medida de lo que hagan exactamente sus datos de simulación.

Por ejemplo, si genera datos secuenciales, entonces puede alimentarlo a su GUI a través de una cola segura o segura para procesos. Pero si muta los datos completos y su GUI necesita poder ver una instantánea en un momento dado, podría ser demasiado costoso resolverlo enviando todo el estado a lo largo de la cola y podría requerir un enfoque tipo mutex para compartir el acceso a la estructura de datos. Entonces, la naturaleza del trabajo realizado en sus datos es primordial aquí.

En cuanto a si usar multiproceso o subproceso, eso depende de si tiene un programa completamente separado o si no maneja los datos.El primero es para hacer multiprocesamiento en el estilo de multihilo: son diferentes partes del mismo programa que se ejecutan en múltiples procesos. El último es cuando un programa quiere ejecutar otro (que podría ser ser una copia del programa, pero por lo general no lo es). De nuevo, es difícil saber cuál es el mejor enfoque para su situación específica, aunque parece que podría tener la lógica del núcleo como una aplicación de línea de comandos y comunicarse a través de tuberías, zócalos, etc.

Answer 3

Para responder las preguntas específicas .

"¿Utilizo el paquete multiprocessing o el paquete subprocess para iniciar el nuevo proceso?"

Uso multiprocessing

"¿Cómo tengo acceso fácil a los datos de la simulación del proceso de interfaz gráfica de usuario?"

No tiene acceso a los objetos de procesos de simulación, si eso es lo que está preguntando La simulación es un proceso separado. Puede iniciarlo, detenerlo y, lo más importante, realizar solicitudes a través de una cola de comandos que van al simulador.

"El usuario debería poder navegar a través de la línea de tiempo de la simulación de manera fácil y sin problemas. ¿Cómo se puede hacer esto?"

Esto es solo diseño. Proceso único, procesos múltiples, hilos múltiples no tienen ningún impacto en absoluto sobre esta cuestión.

Cada simulación debe tener algunos parámetros, debe comenzar, debe producir un registro (o línea de tiempo). Eso tiene que hacerse sin importar qué biblioteca use para iniciar y detener la simulación.

La salida de la simulación, que se ingresa a su GUI, se puede hacer de un millón de maneras.

• Base de datos. La línea de tiempo de simulación podría insertarse en una base de datos SQLite y ser consultada por la GUI. Esto no funciona muy bien porque SQLite no tiene un bloqueo realmente inteligente. Pero funciona

• Archivo. La línea de tiempo de simulación se escribe en un archivo. La GUI lee el archivo. Esto funciona realmente, realmente bien.

• Solicitud/respuesta. La simulación tiene múltiples hilos, uno de los cuales es quitar los comandos y responder, por ejemplo, devolviendo la línea de tiempo hasta el momento, o detener la simulación o cambiar los parámetros y reiniciarlo.

Answer 4

El enfoque más simple que puede funcionar para usted aquí es poner en marcha el cálculo en un hilo separado, y comunicar datos entre este hilo y la interfaz gráfica de usuario utilizando Queue objetos. Estos son completamente seguros y muy convenientes para la comunicación entre hilos.

Otras soluciones son más complejas: puede terminar ejecutando la simulación en un proceso de "servidor" completamente separado y comunicarse con los sockets con la GUI principal.

Answer 5

Mutiprocesamiento o Pyro con objetos de datos distribuidos.

http://pyro.sourceforge.net/

sus suministros de simulación de objetos distribuidos a la interfaz gráfica de usuario, la interfaz gráfica de los manipula y lee sus atributos.

Ambas bibliotecas proporcionarán capacidad de expansión en una red sin problemas, pero pueden ejecutarse localmente. Cuando su simulación comience a procesar demasiados números, agregue más servidores de simulación que proporcionen más objetos distribuidos.