1. Inicio
  2. Pregunta y respuesta
  3. Recomendación de comunicación entre procesos

Recomendación de comunicación entre procesos

2009-12-15 19 views
7

Estoy buscando una manera liviana, rápida y fácil de manejar la comunicación entre procesos entre algunos programas en una máquina con Linux.Recomendación de comunicación entre procesos

Actualmente, estoy pensando en Named Pipe, porque es proporcionado por el propio sistema operativo. ¿Hay alguna advertencia sobre el rendimiento o la usabilidad?

¿La memoria compartida sería mejor?

No creo que necesite un Framework supercomplejo.

Por favor, apúntame en la dirección correcta, ¡gracias!

Actualización: Quiero construir un pequeño programa (demonio) que le dice a otros programas (que ella misma se inicia) para hacer una pausa, informar de su estado hacia atrás, deje etc.

Así que el otro programa debe ser notificado que un nuevo comando lo está esperando. Un tubo no es ideal para eso, ¿verdad?

Fuente

2009-12-15 brandstaetter

Respuesta

4

Boost tiene una buena biblioteca InterProcess que es multiplataforma y bastante intuitiva.

Sin embargo, solo he jugado con eso, por lo que podría haber mejores alternativas.

Sin embargo, si realmente no necesita memoria compartida, me quedaría con un enfoque de mensajería. Evitarás estancamientos y condiciones de carrera. El principio de la tubería es realmente genial, ¡e incluso permite comportamientos perezosos que pueden ahorrarle mucho procesamiento dependiendo del asunto en cuestión!

Fuente

2009-12-15 09:28:30

+0

Eso parece interesante. Lo echaré un vistazo. Siempre me olvido de mirar las bibliotecas de impulso. – brandstaetter

10

Como se ha visto, se puede utilizar para inter comunicación de proceso:

  • Memoria compartida
  • Las canalizaciones con nombre
  • sockets TCP/UDP (eventualmente las locales)

Memoria compartida tiene la ventaja del rendimiento, ya que no tiene ningún búfer al enviar/recibir mensajes. Pero tiene que sincronizar sus intercambios de datos con otro IPC. Puede ser semáforos IPC o ... canalizaciones o zócalos nombrados.

Cuando el rendimiento no es el objetivo principal, tiendo a preferir los enchufes ya que su uso es simple y se puede extender a la comunicación entre computadoras.

La mejor manera es abstraer su comunicación con una clase que pueda usar la memoria compartida cuando los dos procesos estén en la misma computadora y los enchufes si no. A continuación, debe elegir entre UDP y TCP ;-)

Para el intercambio de sincronismo/búfer, prefiera TCP, ya que es más confiable.

No consumo canalizaciones con nombre como yo prefiero zócalo de la posibilidad de usar el ordenador communicationand entre otras, por supuesto, se puede encontrar una gran cantidad de bibliotecas enchufe portátil ...

my2cents

EDIT:

Para la sincronización, la memoria compartida quizás no sea la mejor herramienta.En su caso, puede usarse compartiendo un espacio de memoria pequeño, con un espacio para cada proceso que espera los comandos. Puede sondear cualquier comando entrante o usar un semáforo compartido. La manera más rápida es que sus procesos esperen semáforos con nombre y lean un espacio de memoria compartido para sus comandos/parámetros. Usar tuberías con nombre es seguramente más simple pero no tan rápido. Seguramente no necesitas ser tan rápido? De todos modos, resuma eso en una clase que modele su protocolo de intercambio y pruebe las dos formas :-)

Fuente

2009-12-15 09:30:27 neuro

+0

Me gustaría tener algo sin usar la carga de la pila TCP, ya que se necesita un rendimiento óptimo. Usaremos TCP para comunicarse con otras máquinas también, pero localmente algo más rápido sería ideal. – brandstaetter

+1

@brandstaetter: en este caso, la clave compartida es la forma. Cuanto mayor sea la información, mejor será el rendimiento. Otros IPC (y socket) tienen que almacenar en el búfer, incluso si están optimizados. Con las mem. Compartidas, está seguro de que no hay una sobrecarga del búfer. Usamos memoria compartida para el intercambio de imágenes. El sincronizador se puede hacer con una tubería con nombre o un socket (local), más fácil de administrar que el semáforo compartido (y más portátil). Incluso puede hacerlo sin depender de su protocolo de datos/intercambio ... – neuro

+0

+1 para la capa de abstracción –

1

Utilizaría unix sockets, o alguna biblioteca que los envuelva. Los zócalos Unix son bastante fáciles de usar.

Por otro lado, si tiene información de estado de tamaño fijo para informar, puede hacer que los procesos secundarios lo escriban en un archivo (presumiblemente es pequeño y no lo sincronizará, por lo que no generará carga de trabajo IO significativa).

Fuente

2009-12-15 10:15:20 MarkR

+0

+1: sí, ¿por qué no un archivo? No es la mejor manera de sincronizar, pero puede usar un marcador/contador para la sincronización. – neuro

1

La memoria compartida junto con los semáforos es la más rápida y transparente si desea construir software directamente desde los primitivos.

Las tuberías con nombre no son muy diferentes de las tuberías y funcionan bien entre un par de procesos y no un servidor y muchos clientes.

Si desea construir sobre la infraestructura existente, el dBus es una opción.

La comunicación por socket es versátil y se adapta bien si desea mover sus aplicaciones a través de hosts en una red.

Fuente

2012-07-14 16:48:17 kjohri

Cuestiones relacionadas

 Cuestiones relacionadas