Я пишу программу на C, которая подключается к другому компьютеру через сокет TCP и читает текст с разделителем новой строки через это соединение TCP.
Я использую poll, чтобы проверить, доступны ли данные в файледескриптор, связанный с сокетом, и затем я читаю символы в буфер, пока не получу новую строку.Однако, чтобы сделать это посимвольное чтение эффективным, я использую stdio FILE вместо системного вызова read.
Когда через сокет быстро поступает более одной короткой строки ввода,мой текущий подход имеет ошибку.Когда я начинаю читать символы, stdio буферизует несколько строк данных в пространстве пользователя.После того, как я прочитал одну строку и обработал ее, я poll снова описал дескриптор файла сокета, чтобы определить, есть ли еще данные для чтения.
К сожалению, это poll (и fstat, илюбой другой метод, который я знаю, чтобы получить число байтов в файле), не знает ни о каких оставшихся данных, которые буферизируются в пользовательском пространстве как часть FILE.Это приводит к тому, что моя программа блокируется на poll, когда она должна потреблять данные, которые были буферизованы в пространстве пользователя.
Как я могу проверить, сколько данных буферизуется в пространстве пользователя?Спецификации специально говорят вам не полагаться на setvbuf для этой цели (формат представления не определен), поэтому я надеюсь на другой вариант.
В данный момент мне кажется, что мой лучший вариант - реализоватьмоя собственная буферизация в пользовательском пространстве, где я могу это контролировать, но я хотел проверить перед тем, как идти по этому пути.
РЕДАКТИРОВАТЬ: Некоторые комментарии предоставили способ проверить, есть ли хотя бы один символ, доступный путем установки файлабыть неблокирующим и пытаться fgetc / fungetc одного символа, но это не может сказать вам, сколько байтов доступно.