Правильная обработка EWOULDBLOCK с опросом на неблокирующем сокете

Question

Я работаю над опросом TCP-демона уже некоторое время. Недавно я прочитал, что неблокирующие сокеты могут иногда выдавать ошибку EWOULDBLOCK во время send() или recv(). Насколько я понимаю, если recv () выбрасывает EWOULDBLOCK, это (обычно) означает, что нечего получать. Но что мне неясно, так это то, при каких обстоятельствах send() генерирует EWOULDBLOCK, и какова будет правильная процедура для обработки такого события?

Если send() выбрасывает EWOULDBLOCK, должен ли демон просто перейти от этого события к следующему? При использовании интерфейса опроса, такого как epoll, будет ли запущено новое событие, когда дескриптор станет готовым для записи?

Answer 1

то, что я неясно, при каких обстоятельствах send() бросил бы EWOULDBLOCK

Когда буфер отправки (обычно хранящийся в ОС, но, в любом случае, где-то в стеке TCP/IP) заполнен, и дубликат еще не подтвердил ни один из битов, отправленных ему из буфера (поэтому стек должен сохранять все в буфере на случай необходимости повторной отправки).

Какова была бы правильная процедура для обработки такого события?

Так или иначе, вы должны подождать, пока коллега не подтвердит некоторые отправленные ему пакеты, что позволит стеку TCP/IP освободить место для дополнительной "отправки". Оба классические select и более современный epoll (и в других ОС, kqueue & c) предоставить умные способы выполнить такое ожидание (ожидаете ли вы что-то прочитать, написать что-то или "что из двух случается первым"). Да, наблюдаемые дескрипторы готовятся (будь то для чтения или для записи) является типичной причиной epoll События!