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

Question

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

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

Answer 1

Что мне неясно, так это то, при каких обстоятельствах send () будет выдавать EWOULDBLOCK

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

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

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