История изменений

Я как понял из той ссылке, что приводил, что на OS X адаптивный алгоритм, поэтому при записи в pipe небольшими объёмами буфер будет 16 кбайт, а большими 65 кбайт.

Работать, ИМХО, нужно с pipefd[0], тогда под Линуксом вобще не будет расход лишней памяти, а под BSD и OS X буфер пайпа.

ИМХО, чем меньше памяти уйдёт в пустую, тем лучше, может потом это полукостыльное решение перейдёт в многопотную систему и когда каждый поток «съест» 65 кбайт, то этого объема ОЗУ будет жалко.

Ну я так и сделал. Под нормальными системами, где select() говорит, что pipefd[0] не готов для записи его и возвращаем. А в альтернативно развитых берём pipefd[1], забиваем буфер и возвращаем его. В pipefd[0] забить буфер не получится потому что это дескриптор для чтения по сути и при попытке записи туда возвращается ошибка EBADF. Я выше кидал ссылку на реализацию.

Я как понял из той ссылке, что приводил, что на OS X адаптивный алгоритм, поэтому при записи в pipe небольшими объёмами буфер будет 16 кбайт, а большими 65 кбайт.

Работать, ИМХО, нужно с pipefd[0], тогда под Линуксом вобще не будет расход лишней памяти, а под BSD и OS X буфер пайпа.

ИМХО, чем меньше памяти уйдёт в пустую, тем лучше, может потом это полукостыльное решение перейдёт в многопотную систему и когда каждый поток «съест» 65 кбайт, то этого объема ОЗУ будет жалко.

Ну я так и сделал под нормальными системами, где select() говорит, что pipefd[0] не готов для записи его и возвращаем. А в альтернативно развитых берём pipefd[1], забиваем буфер и возвращаем его. В pipefd[0] забить буфер не получится потому что это дескриптор для чтения по сути и при попытке записи туда возвращается ошибка EBADF. Я выше кидал ссылку на реализацию.