Epoll TCP инициирует необходимость последнего вызова read(2)

Ответ на ваш вопрос находится в man 7 epoll. Как видите, это зависит от типа сокета (пакет/поток):

Q9 Нужно ли мне постоянно читать/записывать дескриптор файла до тех пор, пока не будет EAGAIN при использовании флага EPOLLET (поведение, запускаемое фронтом)?

A9 Получение события от epoll_wait(2) должно означать, что такой файловый дескриптор готов для запрошенной операции ввода-вывода. Вы должны считать его готовым до тех пор, пока следующее (неблокирующее) чтение/запись не даст EAGAIN. Когда и как вы будете использовать файловый дескриптор, зависит только от вас.

Для файлов, ориентированных на пакеты/маркеры (например, дейтаграммный сокет, терминал в каноническом режиме), единственный способ обнаружить конец пространства ввода-вывода для чтения/записи — продолжать чтение/запись до EAGAIN.

Для файлов, ориентированных на поток (например, канал, FIFO, потоковый сокет), состояние, когда пространство ввода-вывода для чтения/записи исчерпано, также может быть обнаружено путем проверки количества данных, считанных из/записанных в целевой файловый дескриптор. Например, если вы вызываете read(2), запрашивая чтение определенного объема данных, а read(2) возвращает меньшее количество байтов, вы можете быть уверены, что исчерпали пространство ввода-вывода чтения для файла. дескриптор. То же самое верно и при записи с использованием write(2). (Избегайте этого последнего метода, если вы не можете гарантировать, что отслеживаемый файловый дескриптор всегда ссылается на файл, ориентированный на поток.)

Это "безопасно" поскольку не произойдет сбой, но если вы не продолжите звонить read, пока не получите EAGAIN (или ноль, что означает, что другой конец закрыл соединение), вы иногда будете ошибаться. предположения о доступности данных. Хуже всего то, что большую часть времени он будет выглядеть так, как будто он работает нормально.

Оповещение, инициируемое границей, а не уведомление, инициируемое уровнем, гарантирует, что вы получите только одно уведомление, если состояние готовности изменилось с момента последнего вызова epoll_wait, даже если остались данные, которые вы могли прочитать.
Уведомление о событии, инициируемое Edge, действительно иногда ведет себя странно или неинтуитивно в Linux, поэтому оно может делать что-то отличное от того, что вы ожидаете, и, например, дать вам еще одно уведомление, когда поступит больше данных (так что ваш код будет работать в любом случае), но это не то, что гарантируется.
У меня были подобные «сюрпризы» при использовании epoll с eventfd. Ожидается, что в режиме с запуском по фронту все потоки, которые уже заблокированы, пробуждаются (все в одно и то же время и ровно один раз), и все, вызывающие epoll_wait после события, блокируются до тех пор, пока событие не будет использовано и подается сигнал снова. На самом деле он пробуждает первый поток, вызвавший epoll_wait. И снова сюрприз, режим с запуском по уровню работает именно так, как вы хотели бы, за исключением того, что вы должны использовать событие, чтобы иметь возможность подготовить его снова, для чего нет правильного способа сделать это (поскольку вы должны сделать это ровно один раз или вы заблокируете read).

Таким образом, если вы не израсходуете все данные и позже дождетесь повторного уведомления, вам может повезти, и оно «все равно сработает», или вы можете ждать довольно долго, возможно, навсегда. Поэтому я рекомендую определенно продолжать чтение, пока не получите EAGAIN, это единственная по-настоящему надежная вещь, позволяющая избежать неожиданностей.

Обратите внимание, что вы можете морить голодом медленных отправителей, если будете продолжать наивно читать. Если у вас очень быстрый отправитель, и вы продолжаете читать на быстром отправителе, то вы никогда не увидите EAGAIN (по крайней мере, до тех пор, пока другой конец продолжает отправлять!), и вы полностью лишите других отправителей.
Это поэтому имеет смысл поместить все готовые дескрипторы в список и читать их циклически, удаляя их из списка, когда они возвращают EAGAIN.