LINUX.ORG.RU

Кто объяснит — зачем в plan9 так извращаются с буфером и, самое главное, _два_раза_ вычисляют длину одних и тех-же аргументов с помощью strlen()?

devpony ()
Ответ на: комментарий от devpony

зачем в plan9 так извращаются с буфером

Чтобы один раз вызвать write. Версия из FreeBSD интереснее, она минимизирует переключения контекста вызовом writev и оптимальнее всех использует память.

baka-kun ★★★★★ ()
Ответ на: комментарий от baka-kun

Какой повод посраться сторонникам KISS и over-engineering... А еще Леннарта некоторые ругают. А он в код GNU echo посмотрел - и все заверте...

slackwarrior ★★★★★ ()

что ты этим пытался доказать? Убогость и ущербность UNIX'а? Да, было такое. Тогда и техника тоже была убогой и ущербной, и современные coreutils на ней надо было лет двадцать компилять.

drBatty ★★ ()
Ответ на: комментарий от devpony

Кто объяснит — зачем в plan9 так извращаются с буфером и, самое главное, _два_раза_ вычисляют длину одних и тех-же аргументов с помощью strlen()?

какая разница? Кодеру показалось, что так проще. У тебя в /bin/echo бутылочное горло? Ты её хоть раз применял? Зачем?

drBatty ★★ ()
Ответ на: комментарий от stevejobs

#if 0

что?

это комментарий такой. Для комментирования кода. А что, никогда не видел что-ли?

drBatty ★★ ()
Ответ на: комментарий от drBatty

Убогость и ущербность UNIX'а?

По-моему наоборот, простоту и элегантность :)

invy ★★★★★ ()
Ответ на: комментарий от invy

По-моему наоборот, простоту и элегантность :)

Белый цвет тоже элегантный.

olibjerd ★★★★★ ()
Ответ на: комментарий от drBatty

я хз где ты такие «боевые серверы в продакшене» видел

leave ★★★★★ ()
Ответ на: комментарий от leave

я хз где ты такие «боевые серверы в продакшене» видел

да чуть более, чем везде, как это не прискорбно. Везде понатыкано нелепое нагромождение непонятно какой НЁХ, с которой хрен как разобраться.

drBatty ★★ ()
Ответ на: комментарий от quantum-troll

я может чего не понимаю в сисколах, но где же потоки?

RedPossum ★★★★★ ()
Ответ на: комментарий от RedPossum

Нет потоков. Либо используешь libthread, где потоки разруливаются самой библиотекой, либо делаешь rfork и получаешь несколько процессов с общей памятью.
Процессы в Plan 9 довольно легковесны, кстати.

http://plan9.bell-labs.com/magic/man2html/2/intro

quantum-troll ★★★★★ ()
Ответ на: комментарий от quantum-troll

В случае Plan 9 системных вызовов тоже немного: segattach, а затем write.

Я бы подумал, что там brk. Создается копия всех аргументов и разделителей. Ну и да, два раза strlen по всем аргументам, как уже сказали.

Во FreeBSD распределяется память только под небольшую структуру, размер которой зависит от количества аргументов, ничего не копируется, и результат выводится по одному сисколу на каждые 1024 аргумента.

baka-kun ★★★★★ ()
Ответ на: комментарий от RedPossum

я может чего не понимаю в сисколах, но где же потоки?

Там есть специальная разновидность процессов, которые шарят с родителем и bss, и data, создаются rfork с флагом RFMEM. Там вообще при создании форка можно выбирать, что унаследует потомок, что проинитится по дефолту, а что будет разделяться с родителем.

baka-kun ★★★★★ ()
Ответ на: комментарий от baka-kun

Я бы подумал, что там brk

Возможно, brk. В любом случае, Plan 9 echo выделяет память под весь вывод, формирует его и передаёт указатель write.
Вывод одним блоком требует выделения памяти.

по одному сисколу на каждые 1024 аргумента

Кто-то использует echo с количеством аргументов, превышающим 9000, и разработчики FreeBSD заботятся, чтобы блоки не были слишком большими?

quantum-troll ★★★★★ ()
Ответ на: комментарий от quantum-troll

Plan 9 echo выделяет память под весь вывод, формирует его и передаёт указатель write.

FreeBSD память не выделяет, а отправляет на вывод готовые строки из *argv[].

Вывод одним блоком требует выделения памяти.

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

разработчики FreeBSD заботятся, чтобы блоки не были слишком большими?

Нет, просто один вызов writev() берет из struct iovec не более IOV_MAX блоков. Думается, для подавляющего большинства запусков echo будет вызван один сискол.

baka-kun ★★★★★ ()
Ответ на: комментарий от baka-kun

если есть системный вызов

Нет там такого системного вызова — разработчики плана не хотят переусложнять ядро.
А в случае FreeBSD даже echo не назовёшь простым.

quantum-troll ★★★★★ ()

всё так

ибо простота использования лиш коррелирует с KISSнатустью реализации

а уж если принять к расмотрению индуцированную обществом «интуитивную понятность » инструмента - то ..

qulinxao ★★☆ ()
Ответ на: комментарий от quantum-troll

Нет там такого системного вызова

Я в курсе, что в Plan 9 нет. Решение продиктовано необходимостью, во FreeBSD код написан из тех же предпосылок. Сперва отказались от буферизованного io, получив экономию по памяти и в размере бинарника (в пять раз во фре) просто заменив всякие printf, puts и putchar на write. А чтобы вернуть производительность пошли разными путями: в плане формируют одну строку из кусочков, а во фре есть сискол, умеющий много кусочков за один вызов. В остальном один фиг, фря только про \c ещё знает.

А в случае FreeBSD даже echo не назовёшь простым.

Да ну?

PS. Кстати, если бы в Plan 9 можно было заменить strcpy() на stpcpy(), избавились бы второго вызова strlen().

baka-kun ★★★★★ ()
Ответ на: комментарий от drBatty

Ну вот хоть убей, но то что в coreutils - это явно перебор. freebsd imho вполне нормально выглядит.

invy ★★★★★ ()

А что за странный синтаксис в примере про UNIX? Причём собирается ведь.

INFOMAN ★★★★★ ()
Ответ на: комментарий от INFOMAN

А что за странный синтаксис в примере про UNIX?

Странный тем, что K&R? Когда-то только так и было.

baka-kun ★★★★★ ()
Ответ на: комментарий от invy

Ну вот хоть убей, но то что в coreutils - это явно перебор. freebsd imho вполне нормально выглядит.

дык катайся на телеге, коняшка. Я же не против.

drBatty ★★ ()
Ответ на: комментарий от INFOMAN

А что за странный синтаксис в примере про UNIX? Причём собирается ведь.

обычный синтаксис. только древний.

Странный тем, что K&R? Когда-то только так и было.

не только.

drBatty ★★ ()
Ответ на: комментарий от drBatty

дык катайся на телеге

Ты не ругайся, а лучше объясни ему, чем различаются BSD echo и SysV echo. :)

не только

Что «не только»? До появления стандарта ANSI C (C89) была только K&R, то есть книга Брайана Кернигана и Денниса Ритчи «The C Programming Language» — первое и долгое время единственное руководство по языку.

baka-kun ★★★★★ ()
Ответ на: комментарий от baka-kun

Ты не ругайся, а лучше объясни ему, чем различаются BSD echo и SysV echo.

дык в коде всё вроде написано ясно.

Что «не только»? До появления стандарта ANSI C (C89) была только K&R, то есть книга Брайана Кернигана и Денниса Ритчи «The C Programming Language» — первое и долгое время единственное руководство по языку.

современный стиль тоже был возможен даже во времена K&R. Я ещё успел в срачах поучаствовать, какой стиль лучше. Или не так?

drBatty ★★ ()
Ответ на: комментарий от drBatty

Или не так?

Не так. Декларации функций как в C++ стандартизированы в ANSI C, до этого были только расширением в некоторых свежих C/C++ компиляторах. В K&R также не было прототипов функций, типы аргументов выяснялись по первому использованию, поэтому в декларации могли отсутствовать (int) или быть по ошибке не теми. Вот не компилируемый пример:

main (c, v)
int c;
char *v[];
{
    int i;

    i = fun(c, v);
    return 0;
}

fun (a, b)
{
    return 1;
}

Чтобы избежать этого и не компилировать мусор, придумали lint, например.

baka-kun ★★★★★ ()
Последнее исправление: baka-kun (всего исправлений: 1)

Нужны ли еще доказательства, что код всё разбухает и разбухает от года к году?

cvs-255 ★★★★★ ()
Ответ на: комментарий от cvs-255

код всё разбухает и разбухает

Двадцать лет назад во всех BSD был один код, затем во FreeBSD добавили \c из iBCS2. Затем, лет десять назад, заменили библиотечный буферизованный вывод на вызов сискола write, что уменьшило размер файла и потребляемой им памяти в пять раз. Вот как бы так.

baka-kun ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.