2011-04-13 5 views
5

Estoy trabajando con algún código que debe ser seguro contra el que llama debido a SIGPIPE, pero las únicas escrituras de socket que está ejecutando van a sockets de datagramas (sockets de datagramas de dominio UDP y Unix). ¿Debo preocuparme por SIGPIPE? Estoy usando connect en el socket, pero las pruebas preliminares (en Linux) mostraron que recibí ECONNREFUSED en el envío si no había nadie escuchando en el socket de dominio de Unix. No estoy seguro de lo que sucede con UDP.¿Puede escribir en un socket de datagrama alguna vez subir SIGPIPE?

Puedo envolver todo en hacks para deshacerse de SIGPIPE, pero si no es un problema, prefiero guardar los gastos generales y mantener la complejidad del código.

+0

Voy a darle una mala respuesta. Creo que lo he visto antes cuando comencé una aplicación cuando el sistema Linux estaba arrancando. No puedo decir si definitivamente fue un socket de datagrama el problema subyacente, pero hasta donde sé, no usamos ningún socket TCP para esa aplicación. Solo un caso de prueba para que usted considere si se aplica a usted. – Jeff

+0

Creo que podría organizar cosas para usar 'sendto' en lugar de' write' así puedo pasar esa bandera que deshabilita 'SIGPIPE'. –

Respuesta

8

La respuesta está en la especificación para send:

[EPIPE] La toma se cierra para escribir, o la toma de corriente es en modo conexión y ya no está conectado. En este último caso, y si el socket es de tipo SOCK_STREAM o SOCK_SEQPACKET y el indicador MSG_NOSIGNAL no está configurado, la señal SIGPIPE se genera a la cadena de llamada.

http://pubs.opengroup.org/onlinepubs/9699919799/functions/send.html

Por lo tanto, no, escribe a los conectores de datagramas no generan SIGPIPE o un error EPIPE.

+0

¿No dice el texto anterior que usted * podría * obtenerlo en UDP si "el socket está apagado para la escritura" (lo que sea que eso signifique)? –

+0

@ T.E.D .: Quizás (si shutdown-for-write funciona en un socket de datagrama), pero esa es una condición que no ocurriría sin la intención o error del programador. No es causado por el par. –

1

Según man 2 write en mi caja Debian,

EPIPE: fd está conectado a una tubería o zócalo cuyo extremo está cerrado lectura. Cuando esto suceda, el proceso de escritura también recibirá una señal SIGPIPE. (Por lo tanto, el valor de retorno de escritura se ve solo si el programa captura, bloquea o ignora esta señal.)

Parece que es posible obtener SIGPIPE al escribir en un socket, pero no está claro si puede suceder para sockets UDP específicamente.

+0

La página de manual para 'enviar' es algo más específica, pero no es tan clara como lo que POSIX dice acerca de' enviar' .. –

+0

De hecho, @R ... He subido la votación y tu respuesta segundos después de que la publicaste. Solo quise hacer rodar la pelota con mi publicación. – ikegami

8

El grupo abierto es una cosa, y Apple es otra. Definitivamente es posible obtener un SIGPIPE en iOS al escribir en un socket UDP muerto, como algunos de mis registros de bloqueo revelaron recientemente. iOS tiende a cerrar sockets UDP mientras la aplicación está en segundo plano, escribiendo en estos sockets puede aparecer un SIGPIPE.
Desde mi registro de bloqueo (cortesía de testflightapp):

Excepción última víctima ocurrencias
SIGPIPE
2 libsystem_c.dylib 0x32df47ec _sigtramp + 48
3 charla instantánea 0x0005b10e - [IPRSNetDatagramSocket enviar: tamaño: a: ] (iprs_iphone_net.m: 671) ...

no recuerdo que esto ocurra en Linux, Solaris o Windows - aunque nunca he tratado de cerrar un socket y luego escribir en él.

+0

Cerrar un socket y luego escribir en él no dará 'SIGPIPE' o' EPIPE'; dará 'EBADF'. iOS debe poner el socket en algún modo especial no estándar para causar 'SIGPIPE'. En cualquier caso, mi pregunta fue etiquetada POSIX porque estaba buscando el comportamiento estándar, pero su respuesta también es informativa. –

Cuestiones relacionadas