¿Cómo realizar operaciones async_ * en el socket a través del cable? Miré Timer.5 (ejemplos de Boost/Asio), pero solo muestran cómo invocar el controlador del usuario. Cuando I async_write en el socket en la aplicación multiproceso datos pueden escribirse dañados. Y un strand garantiza que ninguno de esos manejadores se ejecutará al mismo tiempo.boost :: Asio socket async_ * strand
Desde Boost.Asio docs:
El io_service :: clase cadena ofrece la posibilidad de publicar y despacho manipuladores con la garantía de que ninguno de esos manipuladores ejecutará simultáneamente.
Hay a good example de strand uso en Boost.Asio ejemplos.
strand garantiza que la ejecución de su controlador estará sincronizada. Eso significa que strand es útil si su io_service se ejecuta desde múltiples hilos. No está relacionado con la forma en que programe sus tareas (manejadores).
strand no puede ayudarlo a realizar múltiples operaciones de lectura o escritura de socket al mismo tiempo, porque la ejecución interna de lectura/escritura no se puede realizar al mismo tiempo, por lo que solo debe haber una operación de lectura o escritura asincrónica.
Para reads simplemente llame al async_read para iniciar la secuencia de lectura y volver a llamarla desde su manejador de lectura después de consumir los datos recibidos. Lo mismo que haces en un entorno de un solo hilo.
Para writes si hay productores concurrentes (si varios subprocesos proporciona datos que se escriben en socket) que necesita una cola concurrentes (por ejemplo boost circular buffer, busque "Buffer Ejemplo limitada"). Su función de escritura toma datos de este búfer y async lo escribe en el zócalo. Su controlador de escritura invoca su función de escritura.
Cuando
async_write()a la toma de datos de las aplicaciones multiproceso se puede escribir dañado. Y Strand garantiza que ninguno de esos manipuladores se ejecutará simultáneamente.
Si hay múltiples hilos que necesitan escribir datos en el zócalo, deberá asegurarse de ordenar los datos. Esto está explícitamente claro en el async_write()documentation.
El programa debe asegurar que la corriente no realiza otras operaciones de escritura (como async_write, la función async_write_some de la corriente, o cualquier otra operación que realizan las escrituras compuestas) hasta esta operación se complete.
me sugieren mantener una cola de salida de mensajes, que es muy similar a this question y mi answer.
¿De qué estás teniendo problemas específicamente? La realización de las operaciones asíncronas no es significativamente diferente cuando se usa 'hebra' contra _not_ usando' hebra'. Simplemente envuelva su controlador en el hilo. – Chad
Esta pregunta no tiene sentido como está redactada actualmente, edítela y añada algo de claridad. –
Tiene un sentido perfecto para mí. Estoy teniendo el mismo problema. Múltiples hilos intentan usar una sola conexión de lectura/escritura de respuestas de solicitudes y todo está mal. Lo que intento lograr es una solicitud de lectura secuencial/hacer lo que sea necesario para procesar (incluso otra solicitud/respuesta a un servicio diferente) y luego devolver la respuesta al solicitante original. – Roskoto