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

TC>1 поток обработает ввод/вывод быстрее, чем 100. Я еще забыл написать что 100 поток при сборке программы по умолчанию израсходуют 100М виртуальной памяти, которая будет потом свопиться очень активно .

Ну разве можно после этого представить себе систему лучше линуха?

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

TC>1 поток обработает ввод/вывод быстрее, чем 100. Я еще забыл написать что 100 поток при сборке программы по умолчанию израсходуют 100М виртуальной памяти, которая будет потом свопиться очень активно :).

С какой стати? 1M — это ж reserve size, не commit size. Committed будут дай бог с десяток страниц из каждого потока.

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

TC>Это разные вещи и скорость пееключения в ядро и обратно на порядок выше чем переключение между задачами.
В одном процессе? С чего бы?

TC>Асинхронные методы все естсественным образом включают в себя механизм оповещения.
Ессно включают. Но за ними всеравно нужен глаз да глаз...
Если в линуксе сказать MSG_DONTWAIT то по окончании будет вызвана определенная процедурка.
Те переключение контекста всеравно произойдет.
Болие того если вызов этой процедурки произойдет в другом потоке (используются всплывающие потоки) то и переключение потока тоже произойдет...
В прочем в любом случае придется регистры на стек сохранять.

TC>Более того, с точки зрения ядра все операции — асинхронные,
Вот пусть ядро всем этим и занимается.
TC>просто для некоторых приходиться эмулировать синхронность выполнения ( либо они действительно синхронно могут быть выполнены — т.е без ожидания ).
Так ее в любом случае придется эмулировать не в ядре так у себя.

TC>Можете мне привести хоть из Евангилия цитаты.
Книжка дома.
TC>Асинхронный режим потенциально лучше, по крайней мере IIS работает с сетью именно так.
В винде нужно проверять не закончилась ли посылка... Или можно подождать пока она закончится... заблокировав поток...

TC>А мы же защищаем Windows вроде?
Кто? Где? Не вижу.

TC>Тык если поток обсдуживает устройство ввода/вывода в блокирующем режиме он так и будет делать — не успел получить управление — бац WriteFile — переаланировка, следующий — количеситво переключений будет возратстать.
С асинхронной записью в файл таже фигня...

TC>Этого быть не может — перепланировка случается или по таймеру, или если поток добровольно переведет себя в режим ожидания.
Голову на отсечение даешь? Степень извращения планировщика зависиь исключительно от того кто и зачем этот планировщик пишет.

TC>Регулировать этот пул весьма просто — сколько процессоров в системе, столько и потоков.
Ржу как лошадь.

TC>Я согласен, но в этом случае смысл процесса — совсем другой. IMHO сравнивать системы с вытесняющей многозадачностью и изолированными процессами не корректно.
Так:
1)Процессы по любому изолированны. Вопрос лишь в том какими методами.
2)Метод изоляции процессов (программный или аппаратный) к вытесняющей многозадачности отношения не имеет.

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

Далие насчет синхронности и асинхронности.
Что использовать зависит от того как устроена операционка. Так вот в классические ОС очень часто разумнее использовать синхронную запись ибо с ней гемора меньше.
А в болие модерновых ОС например сингулярити синхронная запись вобще не доступна. Но там асинхронная работа сделана без жуткого гемороя ибо с каналами работать очень легко.

ЗЫ Кстати как ты относишся к процедуре sendfile в линухе?

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

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

_>>>это твое мнение как тестера со стажем, или как программиста, завалившего пачку проектов?
E>>Видимо это и есть, так называемый "переход на личности"?

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

_>+ он просил его (лично) переубедить...

Да нету у меня ни стажа, я не программер, я не тестер, я вообще уже не знаю кто. Мальчишка на побегушках. Держит только зарплата, которая одна из самых высоких в регионе. Да и коллектив хороший.
В последний раз когда писал софтину для облегчения своей работы, мне мой нач сказал — "нах оно тебе нужно? не занимайся хней". Больше я программированием тут заниматься не буду, желания воообще нету чтото сюда писать.
Дайте мне тз, дайте время (а заваленые проекты это я думаеш только программированием занимался? Прграммированием я от силы гдето на 50% занимался, есть и другие обязанности, в том числе и техподдержка была и тогда), и я напишу. Мелкого то софта я нарисовал тут достаточно. А заваленые проекты были уровня rsdn@home, которые я тянул один.

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

AF>С какой стати? 1M — это ж reserve size, не commit size. Committed будут дай бог с десяток страниц из каждого потока.

С этим согласен . Правда страницы по факту коммититься по 64К, т.е их будет не меньше 16 + 3 страницы ядерного стека, который при ожидании юзеровский операций также свопиться. Да к тому же среднее виндовое приложения полюбасу более 64К использует . У меня есть другой аргумент — активное переключение задач будет приводить к постоянному вытеснению стека из кеша процессора, что также при активном использовании стека не есть гуд. .

TC>>Этого быть не может — перепланировка случается или по таймеру, или если поток добровольно переведет себя в режим ожидания.
WH>Голову на отсечение даешь? Степень извращения планировщика зависиь исключительно от того кто и зачем этот планировщик пишет.

Да. Планировшик работает по следующим событиям:
1. Прерывания таймера, допустим раз в 10мс
2. Перевод потока в режим ожидания
3. Установка объект синхронизации в сигнализированное состояние, если этот объект ждет поток с более высоким приоритетом.


TC>>Регулировать этот пул весьма просто — сколько процессоров в системе, столько и потоков.
WH>Ржу как лошадь.
закончим беседу?

WH>Сравнивать управляемые и не управляемые ОС не только можно но и нужно ибо они решают одни и теже задачи.
Но не так. Допустим я сделаю систему с управляемым кодом, где process — это метод объектов и буду в цикле вызывать process у некоторой коллекции объектов. И скажу: "у меня переключение между процессами занимает 10 инструкций машинного кода". Ну-ка, давайте сравним с Windows и с Unix????
В этом случае сравнение не уместно. Сравнивать можно по объективным показателям производительности — скорость ввода/вывода, обработка больших объемов данных и.т.п. Асинхронные операции делают алгоритм

WH>Далие насчет синхронности и асинхронности.
WH>Что использовать зависит от того как устроена операционка. Так вот в классические ОС очень часто разумнее использовать синхронную запись ибо с ней гемора меньше.

Я с этим не спорю. Если есть задача написать серевре которые обслуживает 10000 запросов в час при равномерной интенсивности — тут и думать нечего — однопоточный сервер с блокирующими сокетами.

WH>А в болие модерновых ОС например сингулярити синхронная запись вобще не доступна. Но там асинхронная работа сделана без жуткого гемороя ибо с каналами работать очень легко.
Опять Вы про геморрой, надо же разделять понятия — сложность разработки и производительность решения. Если говорить про Windows, глупо пытаться залепить IOCP в каждую дыру. Но говорить, что блокирующие операции по определению лучше также довольно странно.

WH>ЗЫ Кстати как ты относишся к процедуре sendfile в линухе?
никак, яш пробитый виндуозник

Блин, похоже противников висты не догнать, у них вона уже — 212 постов, а у нас тока 85, надоб поднапрячься

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

ДД>>Если Вы не поняли архитектуру, это не значит, что она кривая.
WH>Ну так объясни.

К сожалению, не обладаю педагогическим даром Если интересно — советую обратиться к соответствующей литературе.

WH>Давить авторитетами бесполезно. Факты давай... факты!

Факты:

ДД>>* передавать дочернему процессу большие массивы данных, не используя дополнительную память.
WH>Для этого форк не нужен.
WH>В разных архитектурах используются разные приемы в винде шарят страници памяти между процессами, а в сингулярити есть exchange heap через которую можно передовать данные любого размера без копирования.

Да, shared memory тоже можно использовать. Но если нужно от родителя передать данные ребенку единожды, а тем более, если нужно чтобы модификация этих данных не была видима второму процессу, то проще (и эффективнее) ничего кроме fork() нету.

ДД>>* переопределить stdin/stdout/stderr простым способом, а не как в CreateProcess()
WH>Уж лучше так чем тот ворох проблем который создает форк.

Если у Вас fork() создает ворох проблем, то это Ваши проблемы, а не fork'а.

ДД>>* знать pid программы до ее запуска
WH>Зачем?

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

WH>Болие того пути шедуллера не исповедимы.

В смысле?

ДД>>* иметь два или более процесса в одном бинарике
WH>Не понял. Надеюсь ты не про совместное использование кода процессами. Так для этого тоже форк не нужен.

Реализовывал я как-то моделирование физического процесса. Ход процесса нужно было отображать в реальном времени, поэтому каждая итерация пересчета синхронизировалась с временем. Но потом оказалось, что в определенной ситуации необходимо "заглянуть в будущее" и узнать результат до того, как рендерер его отобразит. fork(), в дочернем процессе синхронизация пропускается, получаем результат "наперед" без существенной модификации кода.

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

ДД>>и многое другое.
WH>Что именно?

Сколько на данный момент параметров у CreateProcess()? 10, в том числе указатель на структуру из 14 используемых записей. А если нужно ввести еще один параметр — создавать CreateProcessEx()? А еще один — CreateProcessExAdv()? С fork() проще, т.к. ничего выдумывать не надо.

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

WH>ЗЫ Кстати как ты относишся к процедуре sendfile в линухе?

Положительно. Копирование данных выполняется один раз. Со splice() еще меньше.

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

C>>Есть еще vfork

WF>Еще posix_spawn есть, который этот самый vfork может использовать.

И clone(2)

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

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

WH>>Ну печему же? Заходил я пару раз в такие конторки... посмотрел и уходил...
S>Хорошо, когда есть возможность...
"кто хочет, ищет возможности, кто не хочет — ищет отмазки". (с) не помню хто.

S>>>Ты предлагаеш углубляться в библиотечку дотнет?
WH>>Библиотеку нет. Там нет ничего выдающегося. А вот изучить как работают его механизмы JIT, GC... будет очень полезно. Например на RSDN есть статья про то как работает GC в .НЕТ.
S>с++ имхо всетаки побыстрее будет, пусть даже и с qt...
1) в процессе реального девелопмента. важна и скорость разработки
потери в производительности системы — довольны ничтожны
на современных серверах разницы особой нет, работает какая-нибудь enterprise-система на джаве, дотнете или плюсах.
кроме там каких-то особых случаев, где там нужен уж суперпефоманс.
НЕТ РАЗНИЦЫ!!!

2) есть вещи. которые не зависят ни от винды и линукса. ни от конкретного языка программирования, к примеру: database design, OOAD и тд и тп.
почему-то в этом ты не углубляешь знания?
команды языка — ну. это может максимум процентов 30 от того ,что надо
есть гораздо более фундаментальные вещи и они никак не связаны с плюсами, джавами и дотнетом
если ты их понимаешь и применяешь в дотнете, без особых трудностей сможешь применять в джаве и плюсах...
верное и обратное.
вот на чем надо аккцентрировать внимание.


S>>>Все ясно. дотнет рулит, остальное дерьмо, незаслуживающее мозга.
WH>>Что-то тебя на .НЕТ клинит... Да хорошая виртуальныя машина. Но можно было сделать и много лучше.
S>Вот именно.
S>Что непохая это штука — я согласен.
ох#$%ная просто штука, как впрочем и джава не менее ох@#$нная платформа.
обе платформы позволяют делать с высокой скоростью серьезные enterprise-системы, причем, количество человеко-часов гораздо ниже, чем в случае с плюсами и квалификация девелоперов нужна не столь высокая. как в случае плюсов(бюджет проекта нужен меньший — еще один плюс в конкуретной борьбе за заказчика)
а в современной мире жёсткочайшей конкуренции среди аутсорсеров — сроки разработки также играют одну из ключевых ролей в борьбе за заказчика.
а не совсем высокий требуемый уровень разработчиков что на джаве что на дотнете компенсируется наличием фреймворка, которые позволяет предотвратить кучу потенциальных ошибок девелопера и существенно смягчить уже возникшие...

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

3) Джава и дотнет позволяют сущетсвенно облегчить ряд достаточно рутинных операций, над которыми в плюсах надо было тратить время. Это — тоже серьезный фактор, так как высвобождается время. которое можно потратить на улучшение бизнес-логики приложения, либо его архитектуры,

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

WH>>А как насчет того чтобы занятся скажем шароварой? Принципы не позволяют?
S>Не потяну. Ибо требуют быстро, а сам понимаеш, за пару часов в день, которые я могу выделить, ни в какой проект не уложишся.
левый прогон
если ты нормальный девелопер, ты можешь фрилансером быть и забить большую и толстую пиписку на свою текущую работу.
у меня есть несколько знакомых фрилансеров в Харькове. меньше штуки редко когда в месяц имеют.
шароварщики есть знакомые тоже....
ну у них не такой стабильный доход. Иногда и несколько штук в месяц, а иногда и с трудом пару сотен наскребают.
фриланс более стабильный доход и достаточно хорошо оплачиваемый...

вобщем. "кто хочет, ищет возможности, кто не хочет — ищет отмазки". (с) не помню хто.


так что ....

хватит тут гененировать кучу отмазок и давай занимайся реальными проектами и реальными фундаментальными знаниями.

S>>>эээ давай угадаю что так работает... Апач?
WH>>Апач тормоз. Не выдерживающий нагрузку. Это факт медецинский и не раз проверенный. Его даже веб сервер написанный на ерланге (интерпитируемый язык работает гораздо медленней чем .НЕТ...) рвет как тузик грулку.
S>Странные у вас апачи... о_0

Apache vs. Yaws

Yaws — это тот самый сервер, написанный на Эрланге.

Дело в том, что при больших загрузках (например, DDOS на 4 и более тысяч запросов в секунду) умирает даже не Апач, а умирает операционка:

Апач выжирает все доступные потоки системы -> система ему больше физически не может ничего отдать -> Апач ложится и не встает.

В случае с Эрлангом (где потоки легковесны и не затрагивают потоки операционной системы), Эрланг не падает даже на 80 тысячах (!) параллельных соединениях.

Таким образом для обработки 80 000 сообщений одновременно Апачу потребуется кластер из 20 машин, а Эрлангу — одна. И тот факт, что Апач написан на С никак не поможет ему в борьбе с сервером, написанном на интерпретируемом Эрланге

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

WH>>ЗЫ Кстати как ты относишся к процедуре sendfile в линухе?
ДД>Положительно. Копирование данных выполняется один раз. Со splice() еще меньше.
Так он же блокирующий... а тут утверждают что асинхронность рулит всегда...

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

WH>>Голову на отсечение даешь? Степень извращения планировщика зависиь исключительно от того кто и зачем этот планировщик пишет.
TC>Да. Планировшик работает по следующим событиям:
TC>1. Прерывания таймера, допустим раз в 10мс
TC>2. Перевод потока в режим ожидания
TC>3. Установка объект синхронизации в сигнализированное состояние, если этот объект ждет поток с более высоким приоритетом.
Да... придется тебе отрубить себе голову... ибо например планировщик системы реального времени может прервать текущий поток при наступлении любого прирывания (не только от таймера) и переключить на процесс с болие высоким приоритетом (если он был активизирован данным прерыванием). Болие того если вызов не блокирующего метода приведет к тому что проснется (или будет создан) процесс с болие высоким приоритетом то управление также не будет возвращено пока процесс с болие высоким приоритетом не отработает.
При этом политика обращения с остатком кванта может быть любой. Можно его прибавить в следующий раз (но давать работать процессу не больше двух квантов подряд чтобы не забивать процессор), можно просто забить (извини... не повезло... приоритет у тебя маленький...),...

WH>>Сравнивать управляемые и не управляемые ОС не только можно но и нужно ибо они решают одни и теже задачи.
TC>Но не так. Допустим я сделаю систему с управляемым кодом, где process — это метод объектов и буду в цикле вызывать process у некоторой коллекции объектов. И скажу: "у меня переключение между процессами занимает 10 инструкций машинного кода". Ну-ка, давайте сравним с Windows и с Unix????
Процесс это единица выделения ресурсов. Чего нельзя сказать о методе.
Хотя действительно можно сделать систему в которой переключение между процессами будет занимать десятки машинных комманд. Правда для этого нужно отказатся от аппаратной защиты памяти. А еще лучше и от виртуальной памяти... чтобы не тормозила... благо современные объемы памяти позволяют.

TC>В этом случае сравнение не уместно. Сравнивать можно по объективным показателям производительности — скорость ввода/вывода, обработка больших объемов данных и.т.п.
Ну так сингулярити работает на уровне винды с линухом и это при том что ее практически не оптимизировали да и виртуальная машина там так себе.
А если сделать правильную ВМ и оптимизировать то такие ОС порвут классические как тузик грелку.

TC>Асинхронные операции делают алгоритм
Чего?

TC>Я с этим не спорю. Если есть задача написать серевре которые обслуживает 10000 запросов в час при равномерной интенсивности — тут и думать нечего — однопоточный сервер с блокирующими сокетами.
У меня система с блокирующими вызовами держит нагрузку на 2-4 десятичных порядка больше (в зависимости от размера запросов/ответов). И лимитируется пропускной способностью канала.
Что я не так делаю?

WH>>ЗЫ Кстати как ты относишся к процедуре sendfile в линухе?
TC>никак, яш пробитый виндуозник
А она блокирующая... и это самый быстрый способ отправить файл по сетке.

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

ДД>Да, shared memory тоже можно использовать. Но если нужно от родителя передать данные ребенку единожды, а тем более, если нужно чтобы модификация этих данных не была видима второму процессу, то проще (и эффективнее) ничего кроме fork() нету.
Эффективнее? Даже если в родительском процессе несколько потоков? Извини не поверю.

ДД>Если у Вас fork() создает ворох проблем, то это Ваши проблемы, а не fork'а.
Так что там со стартом нового процесса из процесса в котором несколько потоков?

ДД>Например, диспетчер должен запустить процесс так, чтобы его stdout был записан в файл, имя которого содержит pid.
Раскажи это тем кто винду писал.

ДД>Реализовывал я как-то моделирование физического процесса. Ход процесса нужно было отображать в реальном времени, поэтому каждая итерация пересчета синхронизировалась с временем.
Стандартное поведение многих компьютерных игр.
ДД>Но потом оказалось, что в определенной ситуации необходимо "заглянуть в будущее" и узнать результат до того, как рендерер его отобразит. fork(), в дочернем процессе синхронизация пропускается, получаем результат "наперед" без существенной модификации кода.
Это пять! Я плакалЪ! Сочувствую тем кто это потом будет поддерживать.
Я бы при словах синхронизировать по времени создал систему так чтобы можно было объектной модели сказать перейти в следующие состояние.
При словах заглянуть в будущие я бы научил объектную модель клонироваться. Да на С это делать не удобно. На С++ уже много проще. А на какомнибудь .NET или жабе это делается вобще приложением смешного колличества усилий (а для особо ленивых сериализовать/десириализовать в поток в памяти).
А если это делать на функциональном языке то там переход модели в следующие состояние происходит созданием новой модели. При такой системе для заглядывания в будущие вобще делать ничего не нужно... все язык сделает, а оптимизатор спокойно может делать модифицирующие изменеия если не нужно держать копии.

ДД>Или, например, сервер должен каждому клиенту предоставить отдельное адресное пространство. Каждый раз запускать отдельный бинарик, передавая ему необходимые параметры?
1)Чем плох этот вариант?
2)Если используется управляемая система (даже по верх классической ОС например .НЕТ или жаба) то отдельное адресное пространство не нужно.

ДД>Сколько на данный момент параметров у CreateProcess()? 10, в том числе указатель на структуру из 14 используемых записей. А если нужно ввести еще один параметр — создавать CreateProcessEx()? А еще один — CreateProcessExAdv()? С fork() проще, т.к. ничего выдумывать не надо.
А сколько параметров у System.Diagnostics.Process.Start?
То что мелкософты не сделали нормальный интерфейс для CreateProcess не делает форк прямым решением.

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

S>>>Ты предлагаеш углубляться в библиотечку дотнет?
WH>>Библиотеку нет. Там нет ничего выдающегося. А вот изучить как работают его механизмы JIT, GC... будет очень полезно. Например на RSDN есть статья про то как работает GC в .НЕТ.
S>с++ имхо всетаки побыстрее будет, пусть даже и с qt...
Вот чтобы таких вещей не думать, тебе и надо расширять свой кругозор. Дело не в платформе — надо знать вообще, как что работает. Как работает HTTP, к примеру. Как работают управляемые среды. Какие проблемы принципиальны, а какие нет. Каким образом сервера баз данных достигают такой сумасшедшей масштабируемости, и почему MS SQL Server сканирует табличку в 1000 строк настолько медленнее, чем наколенная программка — текстовый файл.
Это все фундаментальные вещи, крайне мало зависящие от языка программирования.

WH>>У нас вобще свой веб сервер который такой фигней не страдает.
S>Дык ясное дело, сервак, написаный под определенную задачу будет лучше работать чем нечто такоеже, но универсальное...
Это тоже миф. Точнее, это утверждение имеет очень ограниченную область применимости, о которой можно случайно забыть. Во-первых, сейчас все больше применяют на практике методики автоматической генерации частных решений по общим (например, JIT-компиляция с оптимизацией под конкретную целевую архитектуру). Это позволяет иметь производительность общего решение не хуже, чем у частного.
Во-вторых, нужно учитывать релятивистские эффекты, т.е. конечность скорости разработки. Реализация частного решения может занять слишком долгое время, чтобы оказаться рентабельной.
В-третьих, частное решение рискует исходить из слишком зауженной постановки задачи. В итоге оно может либо оказаться вообще неприменимым, либо проигрывать по производительности общему решению. Чтобы не быть голословным — парни из Interbase в свое время решили, что некошерно использовать встроенный шедулер Windows. Вместо этого они реализовали внутре кооперативную многозадачность, естественно выиграв на однопроцессорной машине. К несчастью, на многопроцессорной машине интербейз работал из рук вон плохо, т.к. весь выполнялся в одном потоке ОС и не мог загрузить более 1 CPU.

Или отказ от реализации гранулярных блокировок в СУБД может существенно поднять производительность в read-only задачах и в однопользовательской среде по сравнению с "общим случаем". Однако появление уже второго пользователя в read-write задаче сразу отбросит такое решение на задворки.

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

M>В случае с Эрлангом (где потоки легковесны и не затрагивают потоки операционной системы), Эрланг не падает даже на 80 тысячах (!) параллельных соединениях.

Почему? о_0

M>>В случае с Эрлангом (где потоки легковесны и не затрагивают потоки операционной системы), Эрланг не падает даже на 80 тысячах (!) параллельных соединениях.

S>Почему? о_0

Потому что все потоки (которые называются процессами в Эрланге) создаются и живут исключительно внутри виртуальной машины Эрланга. Стоимость создания, поддержки и убивания таких процессов почти нулевая. Просто Эрланг изначально создавался, как язык поддерживающий многопоточность, с упором на "много"

Например, в средней программе, написаной на Эрланге нормально создать несколько тысяч процессов — для Эрланга это естественно, а операционная система никак не затрагивается

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

WH>Эффективнее? Даже если в родительском процессе несколько потоков? Извини не поверю.

Да, эффективнее. И причем здесь потоки? Я не пойму, где ты видишь проблему?
Кстати, знашь ли ты, что далеко не во всех программах требуется многопоточность?

ДД>>Если у Вас fork() создает ворох проблем, то это Ваши проблемы, а не fork'а.
WH>Так что там со стартом нового процесса из процесса в котором несколько потоков?

Так что с ним такого?

ДД>>Например, диспетчер должен запустить процесс так, чтобы его stdout был записан в файл, имя которого содержит pid.
WH>Раскажи это тем кто винду писал.

Я думаю они об этом знают.

ДД>>Реализовывал я как-то моделирование физического процесса. Ход процесса нужно было отображать в реальном времени, поэтому каждая итерация пересчета синхронизировалась с временем.
WH>Стандартное поведение многих компьютерных игр.
ДД>>Но потом оказалось, что в определенной ситуации необходимо "заглянуть в будущее" и узнать результат до того, как рендерер его отобразит. fork(), в дочернем процессе синхронизация пропускается, получаем результат "наперед" без существенной модификации кода.
WH> Это пять! Я плакалЪ!

Ты наверное не понял. Это расширение функциональности было затребовано уже после того, как программа была готова и использовалась.

WH> Сочувствую тем кто это потом будет поддерживать.

А в чем собственно проблема? Изменения в коде: fork() в нужном месте, отключение рендеринга. Флаг, указывающий, это realtime или ускоренный процесс, обход задержки. Обработчик SIGCHLD в родительском процессе для получения результата.

WH>Я бы при словах синхронизировать по времени создал систему так чтобы можно было объектной модели сказать перейти в следующие состояние.

А так по сути и было сделано.

WH>При словах заглянуть в будущие я бы научил объектную модель клонироваться. Да на С это делать не удобно. На С++ уже много проще.

Частично на C++ оно и писалось. Только используемая сторонняя библиотека имела внутренние состояния, а методов доступа к ним не было.

WH>А на какомнибудь .NET или жабе это делается вобще приложением смешного колличества усилий (а для особо ленивых сериализовать/десириализовать в поток в памяти).

Угу, буду я на embeded-устройстве с 128 Мб ОЗУ и 128 Мб флеш-памяти жабу или .NET ставить. Да еще и майкрософту за винду деньги платить.

ДД>>Или, например, сервер должен каждому клиенту предоставить отдельное адресное пространство. Каждый раз запускать отдельный бинарик, передавая ему необходимые параметры?
WH>1)Чем плох этот вариант?

Обращение к ФС. Лишние телодвижения для передачи аргументов. Возможность некорректного запуска бинарика, т.е. с такими параметрами, что он будет думать что он — дочерний процесс, а на самом деле запущен как родительский. Короче, через Ж..

ДД>>Сколько на данный момент параметров у CreateProcess()? 10, в том числе указатель на структуру из 14 используемых записей. А если нужно ввести еще один параметр — создавать CreateProcessEx()? А еще один — CreateProcessExAdv()? С fork() проще, т.к. ничего выдумывать не надо.
WH>А сколько параметров у System.Diagnostics.Process.Start?

Не скажу, ибо не знаю откуда это вообще.

WH>То что мелкософты не сделали нормальный интерфейс для CreateProcess не делает форк прямым решением.

Предложите лучшее решение.

CreateProcess создает процесс и загружет в его пространство указанный модуль. fork() только создает процесс. execve() только загружает в пространство модуль. Так что не совсем корректно сравнивать CreateProcess и fork().
Я не говорю, что fork вообще идеален, и кроме него ничего не нужно. Не зря Линус сделал системный вызов clone(2), в который в итоге оборачивается и fork(), и thread_create. Но в большинстве случаев достаточно просто fork.

Здравствуйте, WolfHound, Вы писали:
WH>Да... придется тебе отрубить себе голову... ибо например планировщик системы реального времени может прервать текущий поток при наступлении любого прирывания (не только от таймера) и переключить на процесс с болие высоким приоритетом (если он был активизирован данным прерыванием). Болие того если вызов не блокирующего метода приведет к тому что проснется (или будет создан) процесс с болие высоким приоритетом то управление также не будет возвращено пока процесс с болие высоким приоритетом не отработает.
Я говорил о работе планировщика в Windows, а не про RTOS. Ясен пень, говорить за все ОС невозможно — я могу написать планировщик как мне заблагорассудиться. Мы говорили о Windows на которой крутяться 100 потоков. А в этой славной ОС планировщик не работает при обработке любого прерывания, а только таймерного. Более того, обработчики прерываний не могут напрямую повлиять на роцесс планировки. Если им это нужно, они регистрят специальную отложенную процедуру, которая как раз и будет выполнена непосредственно перед плнировкой и может на нее повлиять. Так что голову оставлю при себе с ВАшего позволения .


WH>Хотя действительно можно сделать систему в которой переключение между процессами будет занимать десятки машинных комманд. Правда для этого нужно отказатся от аппаратной защиты памяти. А еще лучше и от виртуальной памяти... чтобы не тормозила... благо современные объемы памяти позволяют.
Вроде мы говорили об управляемых системах? Там и не нужна виртуализация памяти с целью создать изолированные пространства, да и защита памяти не нужна — управляемый код по определению не может попасть в чужую память.

WH>А если сделать правильную ВМ и оптимизировать то такие ОС порвут классические как тузик грелку.
Я не спорю кстате с этим. Это только подтверждает мои слова — в то время как системы с типа Windows занимаются всякой ерундой типа перепланировки задач, свопа памяти и.т.п управляемый код будет тупо работать.

TC>>Я с этим не спорю. Если есть задача написать серевре которые обслуживает 10000 запросов в час при равномерной интенсивности — тут и думать нечего — однопоточный сервер с блокирующими сокетами.
WH>У меня система с блокирующими вызовами держит нагрузку на 2-4 десятичных порядка больше (в зависимости от размера запросов/ответов). И лимитируется пропускной способностью канала.
WH>Что я не так делаю?
Во-первых не приводите конфигурацию системы, во вторых imho чуть чуть приувеличиваете — 10 000 * 100, я поверю. Учитывая, что железа и процессоров мы не жалеем, я могу представить себе систему — 8ГБ памяти 4 процессора, получится, что у Вас примерно 50-70 запросов в секунду на каждый процессор. Или по 10мс — вообщем, ничего удивительного, похоже на квант времени . А 10 000 * 10 000 — это около 30000 запросов в секунду, у Вас там лагов немерянно. Хотя рассказать можно все что угодно .

WH>>>ЗЫ Кстати как ты относишся к процедуре sendfile в линухе?
TC>>никак, яш пробитый виндуозник
WH>А она блокирующая... и это самый быстрый способ отправить файл по сетке.
Это ни очем не говорит. Если Вы будете звать ее в цикле для передачи мелких файлов через сеть, то получите следующее — вызов, потеря кванта. Если файл передается быстрее кванта времени — в передаче будут дырки. Асинхронные методы позволили бы этого избежать.