Вопрос по linux, unix, c – В C какой размер буфера стандартного вывода?

7

Сегодня я узнал, что stdout является буферизованной строкой, когда он установлен на терминал и буферизован в различных случаях. Таким образом, в обычной ситуации, если я использую printf () без завершающего символа \ n; он будет напечатан на экране только тогда, когда буфер будет заполнен. Как получить размер этого буфера, насколько он велик?

Если вам не нужна буферизация, почему бы не использовать одну из других стандартных библиотечных функций, для которых она не требуется? Или, возможно, вы могли бы просто включить\n терминатор. Robert Harvey♦
Я просто не знаю, каков размер буфера стандартного вывода. Я знаю, что вы сказали, я просто хочу знать, сколько данных необходимо собрать, чтобы буфер был заполнен и текст выводился на экран user1042840

Ваш Ответ

4   ответа
1

В / proc / sys / fs / pipe-max-size существует максимальный размер трубы. По умолчанию 1048576 является типичным.

Для буфера файлов по умолчанию в glibc; 65536 байт кажется разумным. Однако, как выяснил grep из исходного дерева glibc: libio / libio.h: #define _IO_BUFSIZ _G_BUFSIZ sysdeps / generic / _G_config.h: #define _G_BUFSIZ 8192 sysdeps / unix / sysv / linux / _G_config.h: #define _G_BUFSIZ 8192

Таким образом, первоначальный вопрос может или не может быть дан ответ. На минутное усилие наилучшее предположение составляет 8 килобайт.

Для простой линейной буферизации 8K вполне достаточно. Тем не менее, для более чем строки буферизованного вывода по сравнению с 64К; 8К не эффективен. Потому что для размера трубы по умолчанию используется 64K и если больший размер трубы не ожидается и если больший размер трубы не установлен явно тогда для буфера stdio рекомендуется 64K.

Если требуется производительность тогда скудных 8K буферов не хватит. По fcntl (pipefd, F_SETPIPE_SZ, 1048576) размер трубы может быть увеличен. По setvbuf (стандартный вывод, буфер, _IOFBF, 1048576) предоставленный stdio файловый буфер может быть заменен. Если труба не используется тогда размер трубы не имеет значения. Однако, если между двумя процессами данные передаются по каналу тогда, увеличив размер трубы, можно добиться хороших результатов. Иначе по наименьшему буферу или самой маленькой трубкой узкое место создано.

Если читаешь также затем большим буфером из-за stdio может потребоваться меньше вызовов функции чтения. К слову «мог бы» важное соображение предлагается. Как предусмотрено одним вызовом функции записи одним вызовом функции чтения столько данных можно прочитать. При вызове функции чтения можно ожидать возврата с меньшим количеством байтов, чем запрошено. При дополнительном вызове функции чтения дополнительные байты могут быть получены.

Для записи строки данных; по STDI излишне. Тем не менее, с помощью stdio строки буферизованный вывод возможен. В некоторых сценариях вывод с буферизацией строки необходим. При записи в виртуальную файловую систему proc предоставляется файл или при записи в файл, предоставляемый виртуальной файловой системой sys затем в одном буфере записи должен быть включен байт перевода строки. Если вторая запись используется тогда неожиданным исходом может стать.

Если читать, писать и STDIO смешаны тогда существуют предостережения. До вызов функции записи требуется вызов функции fflush. Потому что stderr не буферизуется; для stderr вызов функции fflush не требуется. При чтении может быть предоставлено меньше ожидаемых байтов. С помощью stdio предыдущие байты могут быть уже буферизованы.

Не рекомендуется смешивать ввод / вывод unistd и stdio, но часто игнорируется. Смешение буферизованного ввода нецелесообразно. Возможно смешивание небуферизованного ввода. Смешивание буферизованного вывода вполне вероятно.

Благодаря буферизации ввода-вывода stdio обеспечивается удобство. Без буферизации ввода-вывода stdio возможно. Однако для кода требуются дополнительные байты. Когда буфер достаточного размера задействован; по сравнению с предоставленными stdio функциями вывода; вызов функции write не обязательно медленнее.

Тем не менее, когда труба не участвует тогда с помощью функции mmap можно обеспечить улучшенный ввод-вывод. На трубе по mmap ошибка не возвращается. Однако в адресном пространстве данные не предоставляются. На трубе по lseek предусмотрена ошибка.

Наконец, man 3 setvbuf - хороший пример. Если в стеке выделен буфер затем перед возвратом вызов функции fclose не должно быть опущено.

Фактический вопрос был "В C, каков размер буфера стандартного вывода?" К 8192 году на это можно было бы ответить.

Те, кто сталкивается с этим запросом может возникнуть любопытство относительно эффективности буфера ввода / вывода. По некоторым запросам цель неявно приближается. Предпочтением кратких ответов значение размера трубы и значение размера буфера и mmap не объясняется. Этот ответ объясняет.

0

Вот Есть несколько довольно интересных ответов на аналогичный вопрос.

в системе Linux вы можете просматривать размеры буфера из различных функций, в том числеulimit. Also the header files limits.h а такжеpipe.h должен содержать такую информацию.

9

стандарт не требует минимального размера (во всяком случае, на основании того, что я смог найти). Не имею понятия о том, как вы определяете размер буфера.

Edit

Глава и стих:

7.19.3 Files ...
3 When a stream is unbuffered, characters are intended to appear from the source or at the destination as soon as possible. Otherwise characters may be accumulated and transmitted to or from the host environment as a block. When a stream is fully buffered, characters are intended to be transmitted to or from the host environment as a block when a buffer is filled. When a stream is line buffered, characters are intended to be transmitted to or from the host environment as a block when a new-line character is encountered. Furthermore, characters are intended to be transmitted as a block to the host environment when a buffer is filled, when input is requested on an unbuffered stream, or when input is requested on a line buffered stream that requires the transmission of characters from the host environment. Support for these characteristics is implementation-defined, and may be affected via the setbuf and setvbuf functions.

Акцент добавлен.

& Quot; Реализация определяемых & Quot; это не эвфемизм для «я не знаю», это просто утверждение, что языковой стандарт явно оставляет его на усмотрениеimplementation вdefine поведение.

И, сказав это, тамis непрограммный способ узнать; обратитесь к документации для вашего компилятора. & Quot; Реализация определяемых & Quot; также означает, что реализацияmust документировать поведение:

3.4.1 1 implementation-defined behavior
unspecified behavior where each implementation documents how the choice is made

2 EXAMPLE An example of implementation-defined behavior is the propagation of the high-order bit when a signed integer is shifted right.
Как я могу увидеть, переполнен ли буфер, наконец, не будет напечатано никаких символов, и он начнется с 1 снова? user1042840
На самом деле это зависит от используемой вами libc, а не от компилятора.
Я слышал "это зависит от реализации" так часто, что я начинаю думать, что иногда это просто способ сказать "я не знаю", но вы сказали это ясно, так хорошо; p user1042840
Вы можете напечатать счетчик символов в stderr (который не буферизирован) и посмотреть, когда появятся первые буферизованные символы, я оставляю реализацию в качестве домашней работы для вас.
& quot; зависит от реализации & quot; означает, что разработчик может реализовать его по своему усмотрению и при этом соответствовать стандарту. если вы действительно хотите знать, насколько велик этот буфер, вы можете продолжать писать в него без & quot; \ n & quot; пока это переполняет.
-2

Вы можете установить его как небуферизованный или просто сбросить.

Похоже, это имеет некоторую приличную информацию, когда среда выполнения C обычно сбрасывает ее для вас и несколько примеров. Взгляни наэтот.

Спасибо, но я хотел бы знать, что вы знаете, сколько данных нужно собрать, чтобы буфер считался полным и текст выводился на экран в Linux или других системах * nik? Каков размер вымышленного буфера, о котором так часто упоминается. user1042840

Похожие вопросы