Evitar la reutilización del mismo número fd en una aplicación multi-hilo conector

Question

que tiene una aplicación asíncrona ejecutar varios hilos que realizan operaciones a través de sockets donde se programan las operaciones y luego ejecutado de forma asíncrona.

Estoy intentando evitar una situación cuando una vez programada una operación de lectura sobre un socket, el socket se cierra y vuelve a abrir (posiblemente otro igual en otra operación) antes de que la primera operación comience a ejecutarse, lo que terminará leyendo el descriptor de archivo correcto pero el par incorrecto.

El problema viene porque (aceptar(); close(); aceptar()) devuelve el mismo fd en tanto acepta() que puede conducir a la situación anterior.

no veo una manera de evitarlo.

¿Alguna pista?

Answer 1

Ok, encontré la respuesta.

La mejor manera aquí es llamar a accept() y obtener el fd más bajo disponible, duplicarlo con un número conocido por usted como dup2 (6,1000) y cerrar (6), ahora tiene el control del rango de fd tu usas.

Siguiente aceptamos vendrá de nuevo con 6 o similares, y vamos a dup2 (6999); y seguir disminuyendo así y reiniciarlo si es demasiado bajo.

Dado que la aceptación se realiza siempre en el mismo subproceso y dup2 y close no son caros en comparación con la aceptación que siempre se hace allí, es perfecto para mis necesidades.

Answer 2

¿Cómo se gestionan los enchufes? Parece que usted tiene múltiples hilos cualquiera de los cuales puede:

1. accept una conexión entrante
2. close una conexión existente
3. hacer una nueva conexión saliente

Parece que usted necesita una manera de para mediar en el acceso a los diferentes enchufes que flotan alrededor. ¿Ha considerado asociar cada socket con mutex que evita cerrar el socket mientras todavía está en uso, o tal vez poner cada descriptor de socket en una estructura con un recuento de referencias atómicas que evitará que otros subprocesos lo cierren hasta que todos los hilos terminen de usarlo?

Answer 3

un socket es un 5-tupla {Local-addr, locales puertos, alejado-addr, remota puertos, proto}, por lo que si usted es capaz de utilizar estas propiedades en lugar de fd para el evento/manejador de enrutamiento que puede evitar el choque fd.

otra opción sería la de serializar todos cerca()/aceptar() Operaciones (prioridades?), De modo que no pueden entremezclar

Answer 4

mantener un recuento de las operaciones pendientes (lectura/escritura, etc.) para cada socket y también si hay una solicitud de cierre pendiente en el socket. Donde antes habría llamado de cerca, verifique primero si hay alguna operación pendiente. Si los hay, llamada apagado en su lugar, y sólo se cierran cuando llame a las operaciones pendientes cuentan llega a 0.

Answer 5

Muy buena pregunta! Ni siquiera me di cuenta de que tal problema podría ocurrir.

La única respuesta que se me ocurre es que no debes Close() para señalar que un socket se termina. Una solución es usar shutdown() para terminar la conexión. Luego puede cerrar() el socket de forma segura mediante el recuento de referencias.

Answer 6

Todavía tendría cuidado de usar dup2() a un valor fd bien conocido. Recuerde que dup2() realizará un cierre en el objetivo antes de duplicar; eso podría entrar en conflicto con algún hilo no relacionado que realice E/S no relacionadas si comienza a tener 1000 archivos abiertos.

Si yo fuera usted, dadas las restricciones que está insistiendo, usaría dup() (no dup2()) dentro de un mutex. (Quizás mutexes por-fd si le preocupa eso).