=?iso-8859-1?q?=5Bcomm=5D_=F0=CF=DE=C5=CD=D5_=C2=D5=C6=C5=D2=C9=DA=C1=C3?= =?iso-8859-1?q?=C9=D1_=CD=C5=CE=D1=C5=D4_=D0=CF=D2=D1=C4=CF=CB_=D7=D9=D7?= =?iso-8859-1?q?=CF=C4=C9=CD=D9=C8_=D7_=C6=C1=CA=CC_=D3=D4=D2=CF=CB=3F?=

[Henri Bourbon]

On 27 Oct 2002  13:53, Valentin Nechayev wrote:

>> Да,   в  свое  время меня очень обескуражил этот эффект. Теперь с этим я
>> разобрался,  непонятно  же  другое:  почему  буферизация  может поменять
>> *порядок* выводимых в файл строк. Поясняю:

> Могут быть и более странные эффекты.
> Дело в том, что если буфера не сброшены явно, то они сбрасываются при
> выполнении exit(). А обычно libc построена так, что они сбрасываются
> в порядке обратном стандартному порядку перечисления, то есть stderr
> сбрасывается раньше, чем stdout.

[skip]

> 1. Из-за того, что не терминал, а пайп - буферизация идет поблочно, а не
> построчно.
> 2. Блоки для stdout и stderr разные.
> 3. Буфер для stderr сбрасывается раньше.

> А еще веселее получается, если stdout и stderr направлены в один пайп,
> а вывода по каждому из них больше чем стандартный размер буфера (обычно 4K,
> AFAIR). Когда буфер сбрасывается не по exit(), строки могут быть разрезаны
> пополам.

> На логи make это обычно не влияет потому, что от каждого процесса
> выдача короткая. Но тоже бывает (если, например, много ошибок и много
> нормального вывода).

Даже не ожидал получить столь фундаментальный ответ :-) Спасибо большое.
/*  По   правде   говоря,   я,   непрограммист,  кое-чего даже недопонял
(насчет  логов make). Но это, может, просто потому, что сейчас 5 утра...
Высплюсь и утром доосмыслю :-)         */

-- 
HB