Здравствуйте, Driver, Вы писали:

...

а у меня новости, индуса с его решением, из-за которого я создал тему, задвинули его же коллеги (я тут вообще не при чем, он из другой команды) и сделали так как я изначально предлагал.

Здравствуйте, Driver, Вы писали:

D>а у меня новости, индуса с его решением, из-за которого я создал тему, задвинули его же коллеги (я тут вообще не при чем, он из другой команды) и сделали так как я изначально предлагал.

Большинство не всегда право. А конкретики ты никакой не рассказал, так что непонятно, стоит ли за тебя радоваться или наоборот.

Здравствуйте, Piko, Вы писали:

P>Ну вот пример типичного "KISS'а" — autotools.
Это ИМХО отличный пример неправильного понимания KISS авторами.
KISS должен соблюдаться во всём. А они как раз в использовании его нарушили чуть менее чем полностью.

Здравствуйте, Eye of Hell, Вы писали:

D>> Вот какой прок лично тебе если ты создал расширяемую, поддерживаемую, документированную систему по сравнению с системой где всех этих плюсов нет (при условии что обе прошли тестирование)?

EOH>Прок в том что потом (через месяц год, пять лет) будет проще поддерживать и развивать.

а вы уверены, что лично вашей карьере это выгодно? я например являюсь свидетелем нескольких случаев, когда на конкретных программистов все очень сильно завязано, и конкретные программисты живут с этого припеваючи...

Здравствуйте, мыщъх, Вы писали:


М>но ведь open (2) откроет что угодно! а вот в вин -- читать/писать в процессы отдельные АПИ вообще. а зачем? считатывать показание счетчиков производительности -- отдельная библиотека вообще. список процессов получить -- еще одна отдельная либа со своим АПИ. с дуба рухнуть можно. а ведь все это хорошо укладывается в концепцию файлов.

Плохо укладывается.
Процесс в NT, является примитивом синхронизации, у него есть сигнальное состояние, которое можно ждать, причем не только родителю (привет posix), а всем подряд. Можно ждать это событие совместно с каким-то еще, все довольно унифицированно. У АП процесса нет "текущей позиции", получается, что для доступа к его адресному пространству лучше придумать что-то получше чем:

int _write(
   int fd,
   const void *buffer,
   unsigned int count 
);

Отдельная функция получения списка процессов дает пользователю возможность получить снимок системы. С файлами такое поведение получить невозможно.

У файлов вообще мало общего с процессами: файл можно переименовывать, файл можно удалить, после чего он не удалится, а перейдет в специальное состояние, различное под NT и posix. Можно отменить его удаление. У него нет "кода выхода".
</режим КЭП'а>
Ну вобщем, я бы не стал смешивать эти две абстракции при проектировании.

НС>И все бы ничего, но у него как то так получалось, что упрощая, он почему то увеличивал сложность тех частей, за которые он не отвечал.


Что совершенно очевидно, ибо сложность задачи — величина конечная снизу. Упростишь один модуль — сложность ляжет на другой. Можно бесконечно перекидывать горячую картошку (особенно, когда за разные модули отвечают разные команды) — но совсем от нее не избавиться.

Здравствуйте, Vamp, Вы писали:

V>Что совершенно очевидно, ибо сложность задачи — величина конечная снизу.

Вот в том то и проблема, что ему это очевидно не было. С тех пор я сторонников KISS воспринимаю крайне настороженно.

Здравствуйте, мыщъх, Вы писали:

М>Здравствуйте, netch80, Вы писали:

N>>Здравствуйте, мыщъх, Вы писали:

М>>>Здравствуйте, Driver, Вы писали:

N>>Ну если вспоминать именно CreateFile() с её специфическим стилем, то принципиальная разница от open() в том, что в CreateFile() каждая отдельная характеристика метода открытия вынесена в свой метод, а у open() одна общая битовая маска flags. Второе действительно удобнее в нескольких аспектах — разумно понятное количество аргументов и расширяемость (например, было тривиально добавить O_NOFOLLOW, а покажите мне аналог под Windows), но принципиального различия, мне кажется, нет. Одно в другое переходит.

М>но ведь open (2) откроет что угодно! а вот в вин -- читать/писать в процессы отдельные АПИ вообще. а зачем? считатывать показание счетчиков производительности -- отдельная библиотека вообще. список процессов получить -- еще одна отдельная либа со своим АПИ. с дуба рухнуть можно. а ведь все это хорошо укладывается в концепцию файлов.

Ну если так рассуждать то и в винде через syscall можно что угодно открыть %) Все укладывается в концепцию адресов и регистров.
Ну накатаете вы свои обертки-велосипедики поверх open для разных задач. Да это будет только нужное вам подмножество API, да это будут — родные, знакомые вам велосипедики. Но благодаря этой "простоте" вы только что зря потратили время.

А если понадобиться формат данных поменять — /procEx будем делать? Или по линуксовски забъем на совместимость?

Здравствуйте, Ligen, Вы писали:

М>>но ведь open (2) откроет что угодно! а вот в вин -- читать/писать в процессы отдельные АПИ вообще. а зачем? считатывать показание счетчиков производительности -- отдельная библиотека вообще. список процессов получить -- еще одна отдельная либа со своим АПИ. с дуба рухнуть можно. а ведь все это хорошо укладывается в концепцию файлов.

L>Плохо укладывается.
L>Процесс в NT, является примитивом синхронизации, у него есть сигнальное состояние, которое можно ждать, причем не только родителю (привет posix), а всем подряд. Можно ждать это событие совместно с каким-то еще, все довольно унифицированно. У АП процесса нет "текущей позиции", получается, что для доступа к его адресному пространству лучше придумать что-то получше чем:
L>

L>int _write(
L>   int fd,
L>   const void *buffer,
L>   unsigned int count 
L>);
L>

L>Отдельная функция получения списка процессов дает пользователю возможность получить снимок системы. С файлами такое поведение получить невозможно.

Вы какую-то несуразную мистику рассказываете. Посмотрите на Linux.
Список процессов? Пожалуйста, opendir("/proc"), прочитали список подкаталогов и отобрали все имена, что из одних цифр.
У адресного пространства процесса нет текущей позиции? Но ведь у файла, который его изображает, ничто не мешает сделать такую текущую позицию. Надо? Открываем /proc/$pid/mem и работаем с этим адресным пространством. (В реальности .../mem немного другое, но это был учебный пример.)
Нужно прочитать с какого-то места? lseek() и затем read(). Ну да, можно pread(), чтобы сразу с этого места читать, там и позиция передаётся. Зачем что-то навороченное ещё изобретать, когда все примеры под рукой?

Ну да, надо было уточнить, что речь не о просто файлах, а об FS. Но это jIMHO непринципиально.

L>У файлов вообще мало общего с процессами: файл можно переименовывать, файл можно удалить, после чего он не удалится, а перейдет в специальное состояние, различное под NT и posix. Можно отменить его удаление. У него нет "кода выхода".

WTF "код выхода"?

L></режим КЭП'а>

Какой-то плохой, негодный кэп у вас получился. Ладно бы начал рассказывать о неэффективности подхода, это ещё имеет какой-то смысл. Но когда о полной невозможности... отправьте его на пенсию.

Здравствуйте, Banned by IT, Вы писали:

М>>но ведь open (2) откроет что угодно! а вот в вин -- читать/писать в процессы отдельные АПИ вообще. а зачем? считатывать показание счетчиков производительности -- отдельная библиотека вообще. список процессов получить -- еще одна отдельная либа со своим АПИ. с дуба рухнуть можно. а ведь все это хорошо укладывается в концепцию файлов.
BBI>Ну да, когда в руках молоток — весь мир похож на гвоздь.
BBI>Ну и как ты это всё впихаешь в концепцию файлов? Те же обращения к памяти процесса и счётчики.

Ну счётчики — ещё может быть, но обращения к памяти процесса — см. мой предыдущий по времени ответ сюда — всё тривиально делается.

BBI>Я имел сомнительное удовольствие иметь дело с API, в которых, если проводить аналогию с темой этой ветки "процесс как файл": если мы открыли процесс как файи и читаем оттуда по 4 кб то это будет читаться память процесса а если по 123 байта то будет читаться perfcounter.
BBI>API этот состоял из буквально пары функций, но использование его напоминало зверское колдунство с кучей magic numbers.

Сдуру можно и нефритовый стебель сломать (tm), но зачем так делать?

Здравствуйте, netch80, Вы писали:

М>>>но ведь open (2) откроет что угодно! а вот в вин -- читать/писать в процессы отдельные АПИ вообще. а зачем? считатывать показание счетчиков производительности -- отдельная библиотека вообще. список процессов получить -- еще одна отдельная либа со своим АПИ. с дуба рухнуть можно. а ведь все это хорошо укладывается в концепцию файлов.
BBI>>Ну да, когда в руках молоток — весь мир похож на гвоздь.
BBI>>Ну и как ты это всё впихаешь в концепцию файлов? Те же обращения к памяти процесса и счётчики.

N>Ну счётчики — ещё может быть, но обращения к памяти процесса — см. мой предыдущий по времени ответ сюда — всё тривиально делается.
Как именно тривиально?
Ты кстати в курсе что у памяти процесса на разные страницы ещё и разные права доступа вешаются, и что их как то читать/менять надо?

N>Сдуру можно и нефритовый стебель сломать (tm), но зачем так делать?
Ну мне твои предложения очень уж это напоминает.

Здравствуйте, igna, Вы писали:

...
I>Большинство не всегда право. А конкретики ты никакой не рассказал, так что непонятно, стоит ли за тебя радоваться или наоборот.

скорее всего большинство тут не при чем, но большинство право всегда — таково условие работы в команде. Конкретики слишком много чтобы тут описывать, а основные характеристики индусского подхода полагаю известными. Вопрос в преимуществах и недостатках различных подходов.

Здравствуйте, Banned by IT, Вы писали:

N>>Ну счётчики — ещё может быть, но обращения к памяти процесса — см. мой предыдущий по времени ответ сюда — всё тривиально делается.
BBI>Как именно тривиально?

Ты его прочитал?

BBI>Ты кстати в курсе что у памяти процесса на разные страницы ещё и разные права доступа вешаются, и что их как то читать/менять надо?

Если ты говоришь просто о чтении/записи, то ничего такого не нужно: ты этим просто помешаешь процессу.
Но если тебе зачем-то приспичило их поменять, для этого можно придумать ioctl'и. А дальше можешь нарисовать, если тебе нужно, своё API вокруг них.

N>>Сдуру можно и нефритовый стебель сломать (tm), но зачем так делать?
BBI>Ну мне твои предложения очень уж это напоминает.

Я как раз рассказываю о том, что работает без проблем, в ответ на мифы о том, что это или невозможно, или безумно.

Здравствуйте, Константин Б., Вы писали:
КБ>А если понадобиться формат данных поменять — /procEx будем делать? Или по линуксовски забъем на совместимость?

А зачем понадобится формат данных поменять?

Здравствуйте, netch80, Вы писали:


L>>Отдельная функция получения списка процессов дает пользователю возможность получить снимок системы. С файлами такое поведение получить невозможно.

.....

N>Какой-то плохой, негодный кэп у вас получился. Ладно бы начал рассказывать о неэффективности подхода, это ещё имеет какой-то смысл. Но когда о полной невозможности... отправьте его на пенсию.

Я наверное немного запутанно выразился. Тут я имел ввиду, что интерфейс перечисления файлов в большинстве систем расчитан на то, что файлов в директории может быть очень много, и их перебор полюбому будет делаться в несколько итераций (в windows это FindFirstFile + FindNextFile, или в ядре IRP_MJ_DIRECTORY_CONTROL, в posix насколько я помню readdir). Естественно, пока идет перебор файлов, их количество в директории может меняться, поэтому при большой файловой активности в одной директории результат может быть неконсистентным.

Функция же получения всех процессов (NtQuerySystemInformation) сдизайнена так, что возвращает список процессов одним буфером, т.е. есть некоторый шанс того, что список будет действительно соответствовать состоянию системы в некоторый момент времени. И в 2к оно так и было, прямо под одним локом весь список копировался в user buffer, в xp правда все уже не так.

Здравствуйте, netch80, Вы писали:

BBI>>Ты кстати в курсе что у памяти процесса на разные страницы ещё и разные права доступа вешаются, и что их как то читать/менять надо?
N>Если ты говоришь просто о чтении/записи, то ничего такого не нужно: ты этим просто помешаешь процессу.
N>Но если тебе зачем-то приспичило их поменять, для этого можно придумать ioctl'и. А дальше можешь нарисовать, если тебе нужно, своё API вокруг них.
И вот мы вышли обратно на дерибасовскую...
Если процесс представлять как файл то всё равно придётся делать костыли.
Какая уже тут разница, отдельный API для него или эмуляция через файлы. Но в случае с отдельным API нам не придётся писать подпорки чтоб реализовывать отличия процесса от файла. API выходит чище.

Здравствуйте, gegMOPO4, Вы писали:

КБ>>А если понадобиться формат данных поменять — /procEx будем делать? Или по линуксовски забъем на совместимость?

MOP>А зачем понадобится формат данных поменять?
Evolution, baby! (C)

Здравствуйте, Banned by IT, Вы писали:
BBI>Здравствуйте, gegMOPO4, Вы писали:
КБ>>>А если понадобиться формат данных поменять — /procEx будем делать? Или по линуксовски забъем на совместимость?
MOP>>А зачем понадобится формат данных поменять?
BBI>Evolution, baby! (C)

Это революция. При грамотной эволюции проблем не так уж много.

Здравствуйте, Driver, Вы писали:

D>Навеяно общением с идусским дизайнером...

D>У меня тут создалось впечатление, что индусские программисты склонны к "размазыванию" логики и данных по максимальному количеству компонентов (классов, модулей, хранимых процедур и т.п.). Делают они это весьма уверенно и, помоему, подсознательно. Единственно рациональное объяснение это так они закрепляются на своем месте, т.к. им одним постижим принцип построения этой логики. Возможно им просто так комфортно, а раз комфортно то увеличивается продуктивность.

Индусские — это слишком мягко сказано. Европейцы, американцы и даже русские слишком часто создают код который ничем не лучше индусского.

Здравствуйте, Ikemefula, Вы писали:

...
I>Индусские — это слишком мягко сказано. Европейцы, американцы и даже русские слишком часто создают код который ничем не лучше индусского.

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