Должен ли я утверждать сбой при выборе() EBADF?

Question

Я пытаюсь исправить ошибку в цикле событий, который вызывает select(). Когда select() возвращает EBADF, регистрируется ошибка, тогда набор fd повторно инициализируется и выбор вызывается снова. Это приводит к бесконечному жесткому циклу регистрации, генерируя гигабайты журнала в считанные секунды.

Эта ошибка возникает, если один из серверов tcp, к которому подключена моя программа, выполняет нечистое отсоединение (например, segfaults). В этом случае я бы идеально хотел, чтобы моя программа удаляла этот fd и продолжала работать (или отключается, если это невозможно).

Мой вопрос в том, должен ли() когда-либо возвращаться EBADF, или это указание на то, что моя программа глючит? То есть Должен ли я утверждать, что я не согласен с EBADF, или каким-то другим образом, как мне обращаться с ним? Пропустил бы ли я цикл fd, чтобы найти «плохой» дескриптор файла?

Answer 1

У вас есть ошибка в коде. Почини это. Где-то вы закрываете сокет, не удаляя его из набора FD, используемого селектором. Или вы только что составили FD, который не является FD и использует его в наборе FD.

В отличие от других утверждений, сетевые проблемы не могут вызвать эту ошибку. Неисправности сети не закрывают сокеты, и это единственный способ стать недействительными. Это только закрытие. Сокет, соединение которого не работает, в конечном итоге вызовет ECONNRESET, если вы сохраните его. Сокет, чей одноранговый узел отсоединился, станет читаемым, и recv() на нем вернет нуль.

Answer 2

Да, я думаю, это было бы неплохо для assert().

На странице select(2) людей:

EBADF недопустимый дескриптор файла был дан в одном из множеств. (Возможно, дескриптор файла, который уже был закрыт, или один на , которая произошла ошибка.)

Это означает, что вы прошли дескриптор файла, который на самом деле не совпадает действующий открытый файл.

Примеры сценариев, которые не вызвать FD, чтобы сделать select неудачно с EBADF:

• Удаленный сокет закрытия соединения. (recv возвращает 0).
• Отключение сетевого подключения (или даже USB-устройства).

---

Глядя на исходный код ядра Linux, мы видим, что select может вернуться EBADF, если будет установлено, что один из FDS, переданных в вашем наборе не соответствует открытому файлу в вашем процессе. Это проверяется в max_select_fd в fs/select.c

После этой проверки do_select всегда будет возвращать счетчик «интересных» фс. Функция file_operations.poll для базового файла даже не способна сделать do_select вернуть что-то другое.

Теперь выглядит полностью невозможно, что select вернется EBADF для любого сценария, кроме программирования пропускания FD, которая была либо закрыта, либо никогда не откроется.

Answer 3

Мой вопрос в том, должен ли() когда-либо возвращаться EBADF, или это указывает на то, что моя программа глючит?

select() возвращает EBADF, если вы передадите дескриптор в одном из недопустимых fd_set.Вы не должны этого делать, и это указывает на ошибку в вашей программе - возможно, вы закрыли(), где-то в файловом дескрипторе, но не удалили ее из fd_set.