Может ли запись в сокет дейтаграмм когда-либо поднять SIGPIPE?

Я работаю с некоторым кодом, который должен быть защищен от уничтожения вызывающего абонента из-за SIGPIPE, но единственный сокет, который пишет, что он выполняется, собирается в сокеты дейтаграмм (как UDP, так и сокеты дейтаграмм домена Unix). Мне нужно беспокоиться о SIGPIPE? Я использую connect в сокете, но предварительное тестирование (в Linux) показало, что я просто получаю ECONNREFUSED при отправке, если никто не прослушивает сокет домена Unix. Не уверен, что происходит с UDP.

Я могу обернуть все это в хаки, чтобы избавиться от SIGPIPE, но если это не проблема, я бы предпочел сэкономить накладные расходы и снизить сложность кода.


person R.. GitHub STOP HELPING ICE    schedule 13.04.2011    source источник
comment
Я собираюсь дать вам плохой ответ. Я думаю, что видел это раньше, когда запускал приложение во время загрузки системы Linux. Я не могу сказать, была ли основная проблема определенно сокетом дейтаграммы, но, насколько я знаю, мы не использовали сокеты TCP для этого приложения. Просто тестовый пример для вас, чтобы рассмотреть, может ли это относиться к вам.   -  person Jeff    schedule 14.04.2011
comment
Я думаю, что я мог бы просто организовать использование sendto вместо write, чтобы я мог передать этот флаг, отключающий SIGPIPE.   -  person R.. GitHub STOP HELPING ICE    schedule 14.04.2011


Ответы (3)


Ответ находится в спецификации для send:

[EPIPE] Сокет закрыт для записи или сокет находится в режиме соединения и больше не подключен. В последнем случае, если сокет имеет тип SOCK_STREAM или SOCK_SEQPACKET и флаг MSG_NOSIGNAL не установлен, для вызывающего потока генерируется сигнал SIGPIPE.

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

Таким образом, нет, запись в сокеты дейтаграмм не генерирует ошибку SIGPIPE или EPIPE.

person R.. GitHub STOP HELPING ICE    schedule 13.04.2011
comment
Разве приведенный выше текст на самом деле не говорит, что вы можете получить его по UDP, если сокет закрыт для записи (что бы это ни значило)? - person T.E.D.; 11.02.2017
comment
@TED: Возможно (если отключение для записи работает на сокете дейтаграммы), но это условие, которое не произошло бы без намерения или ошибки программиста. Это не вызвано пэром. - person R.. GitHub STOP HELPING ICE; 11.02.2017

Открытая группа — это одно, а Apple — другое. Определенно возможно получить SIGPIPE на iOS при записи в мертвый сокет UDP, как недавно показали некоторые из моих журналов сбоев. iOS имеет тенденцию закрывать сокеты UDP, когда приложение находится в фоновом режиме, запись в эти сокеты может вызвать SIGPIPE.
Из моего журнала сбоев (любезно предоставлено testflightapp):

Exception Latest Victim Occurrences
SIGPIPE
2 libsystem_c.dylib 0x32df47ec _sigtramp + 48
3 Instant Talk 0x0005b10e -[IPRSNetDatagramSocket send:size:to:] (iprs_iphone_net.m:671)...< бр/>

Не помню, чтобы это происходило в Linux, Solaris или Windows, хотя я никогда не пытался закрыть сокет, а затем писать в него.

person Moshe Gottlieb    schedule 12.09.2012
comment
Закрытие сокета с последующей записью в него не даст SIGPIPE или EPIPE; это даст EBADF. iOS должна перевести сокет в какой-то особый нестандартный режим, чтобы вызвать SIGPIPE. В любом случае мой вопрос был помечен как POSIX, потому что я искал стандартное поведение, но ваш ответ тоже информативен. - person R.. GitHub STOP HELPING ICE; 12.09.2012

Согласно man 2 write на моем компьютере с Debian,

EPIPE: fd is connected to a pipe or socket whose reading end is closed. When this happens the writing process will also receive a SIGPIPE signal. (Thus, the write return value is seen only if the program catches, blocks or ignores this signal.)

Оказывается, можно получить SIGPIPE при записи в сокет, но не ясно, может ли это произойти конкретно для сокетов UDP.

person ikegami    schedule 13.04.2011
comment
Страница руководства для send несколько более конкретна, но не так ясна, как то, что POSIX говорит о send. - person R.. GitHub STOP HELPING ICE; 14.04.2011
comment
Действительно, @R ... Я проголосовал за ваш ответ через несколько секунд после того, как вы его опубликовали. Я просто хотел сдвинуть дело с мертвой точки своим постом. - person ikegami; 14.04.2011