2010-01-12 9 views
5

Hola desbordamiento de la pila: a veces lector, primer póster.IPC entre la aplicación Python y la DLL inyectada

Antecedentes:

cuadro de Windows que se ejecuta XP SP3, que pronto será actualizado a Windows Seven (MSDN AA < 3)

tengo una DLL inyectado que se pone ciclos enganchando una función que se llama miles de veces un segundo.

Me gustaría comunicar/controlar esta DLL a través de una aplicación de Python. Básicamente, la DLL hace el trabajo, la aplicación de Python suministra los cerebros/toma de decisiones.

Mi plan de juego para hacer esto es tener un contador y una instrucción if en la DLL. Cada vez que se llama a la función enganchada, counter ++ y luego retrocede a la función original hasta algo así como if (counter == 250) {// dostuff(); }. Mi pensamiento detrás de esto permitirá que la aplicación de destino se ejecute casi sin obstáculos, pero aún así me dejará hacer cosas interesantes.

Problema:

Estoy en una pérdida absoluta de qué método IPC debo utilizar para hacer la comunicación. Tenemos sockets, memoria compartida, pipes, filemapping (?), RPC y otras cosas (aparentemente) esotéricas, como escribir en el portapapeles.

NUNCA he implementado ningún tipo de IPC aparte de ejemplos de juguetes.

Estoy bastante seguro de que necesito algo que:

  • Puede manejar hablando de ida y vuelta entre el pitón y una DLL
  • no bloquea/esperar
  • puede comprobar si la espera de datos, y continuar si no hay ninguna
  • Si las cerraduras están involucrados, se puede seguir en lugar de esperar
  • no cuesta mucho tiempo para leer/escribir demasiado

¿Ayuda? Gracias por su tiempo, espero haber proporcionado suficiente información general y no haber roto ninguna de las convenciones aceptadas.

Me gustaría agregar que el cuadro de preguntas relacionadas es muy bueno, y lo analicé antes de publicarlo.

Respuesta

2

Pruebe los sockets. Sus demandas son esencialmente un requisito de funcionamiento asincrónico; Python tiene el módulo asyncore para IO asíncrono en sockets. Al mismo tiempo, no parece que el archivo stdlib de Python pueda manejar asincrónicamente otras cosas de IPC, por lo que no recomendaría su uso.

1

Si no te importa en tiempo real, puedes utilizar el sistema de archivos para la comunicación: un archivo de registro para el resultado de la DLL y un archivo de configuración que se lee de vez en cuando para cambiar el comportamiento de las DLL.

+1

El uso de un archivo de registro es * no * un IPC en absoluto. – ulidtko

+0

@ulidtko El sistema de archivos es la forma más antigua y confiable de sincronización de IPC. Es por eso que el estándar POSIX tiene la misma API para todas las formas de IPC. Dado que el sistema operativo ** debe ** administrar la coherencia y la sincronización en las operaciones del sistema de archivos (o no llamarse sistema operativo), el sistema de archivos es la implementación más sencilla de IPC para usar en programas que no son del sistema operativo. Pruebe 'ls/var/run/*.pid' la próxima vez que tenga acceso a un sistema * nix. – Apalala

+1

La impresión es una forma aún más antigua y confiable de ... almacenar información en papel. OS ** debe ** administrar la coherencia de lo que se imprimirá, y cualquier ser humano puede administrar toda la sincronización necesaria. ¿Por qué no intentas imprimir un "Hola mundo"? en papel, y luego escanear y OCR-ing para controlar su programa? Lo siento, pero tu comentario no es solo un argumento. Las impresoras deben imprimir documentos, los sistemas de archivos deben almacenar archivos, shmem-pipes-sockets deben proporcionar las formas de hacer IPC. – ulidtko

Cuestiones relacionadas