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

WH>Так он же блокирующий... а тут утверждают что асинхронность рулит всегда...

Я согласен с тем, что асинхронность рулит не всегда.
Но где написано, что он блокирующий? Просто не встречал такой информации.

Mamut wrote:
> В случае с Эрлангом (где потоки легковесны и не затрагивают потоки
> операционной системы), Эрланг не падает даже на 80 тысячах (!)
> параллельных соединениях.
Зато Yaws ляжет, если каждому из потоков нужно будет отдать файл
размером в 10Мб. Просто из-за того, что Apache использует sendfile,
который работает в режиме ядра.

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

При желании с помощью splice можно одновременно писать в буффер, из
которого драйвер устройства в это же время уже читает данные.

C>Mamut wrote:
>> В случае с Эрлангом (где потоки легковесны и не затрагивают потоки
>> операционной системы), Эрланг не падает даже на 80 тысячах (!)
>> параллельных соединениях.
C>Зато Yaws ляжет, если каждому из потоков нужно будет отдать файл
C>размером в 10Мб. Просто из-за того, что Apache использует sendfile,
C>который работает в режиме ядра.

Возможно, не спорю. Но это надо замеры производить или прикручивать sendfile к yaws

Mamut wrote:
> C>Зато Yaws ляжет, если каждому из потоков нужно будет отдать файл
> C>размером в 10Мб. Просто из-за того, что Apache использует sendfile,
> C>который работает в режиме ядра.
> Возможно, не спорю. Но это надо замеры производить или прикручивать
> sendfile к yaws
А не получится прикрутить — он блокирующийся То есть нужно будет
создавать пул системных потоков, которые будут выполнять sendfile. Ну в
общем, Апач и получится в итоге.

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

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

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

WH>>Эффективнее? Даже если в родительском процессе несколько потоков? Извини не поверю.
ДД>Да, эффективнее. И причем здесь потоки? Я не пойму, где ты видишь проблему?
При том что они тоже клонируются... и начинают страници инвалидировать...

ДД>Кстати, знашь ли ты, что далеко не во всех программах требуется многопоточность?
Знаю.

WH>>Так что там со стартом нового процесса из процесса в котором несколько потоков?
ДД>Так что с ним такого?
ТОРРРРРМОЗЗЗАААА!!!!

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

ДД>Ты наверное не понял. Это расширение функциональности было затребовано уже после того, как программа была готова и использовалась.
Я понял. Просто я не понял какие проблемы склонировать модель? Или ты написал программу в худших традициях фортрана?

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

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

ДД>Угу, буду я на embeded-устройстве с 128 Мб ОЗУ и 128 Мб флеш-памяти жабу или .NET ставить. Да еще и майкрософту за винду деньги платить.
1)128 метров памяти болие чем достаточно для того чтобы поднять жабу.
2)Так причем тут винда? Жаба на линуксе работать умеет.
3)Это легко делается везде где есть рантайм рефлексия или еще лучше метапрограммирование.

ДД>Обращение к ФС.
Ты хотел сказать обращение к уже загруженному в память бинарному образу. Причем никто его клонировать не будет. Его зашарят.
По твоему туже винду совсем идиоты писали?
ДД>Лишние телодвижения для передачи аргументов.
Какой кошмар... берешь любой OORPC хоть COM хоть CORBA и никаких проблем.
А в системах с метаинформацией вобще и управляемых ОС в частности можно делать входные точки процесса с произвольной сигнатурой.
ДД>Возможность некорректного запуска бинарика, т.е. с такими параметрами, что он будет думать что он — дочерний процесс, а на самом деле запущен как родительский.
А зачем ему это вобще знать?
ДД>Короче, через Ж..
И это говорит любитель форка...

WH>>А сколько параметров у System.Diagnostics.Process.Start?
ДД>Не скажу, ибо не знаю откуда это вообще.
Это из библиотеки .НЕТ

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

CreateProcessInfo processInfo;
InitCreateProcessInfo(&processInfo, CREATE_PROCESS_INFO_VERSION);
processInfo.imageName = "C:\\superPuper.exe";
HANDLE stdIn = InterceptStdStream(&processInfo, STDSTREAM_IN);
HANDLE stdOut = InterceptStdStream(&processInfo, STDSTREAM_OUT);
HANDLE stdErr = InterceptStdStream(&processInfo, STDSTREAM_ERR);
CreateProcess(&processInfo);

InitCreateProcessInfo не переходит в режим ядра ибо не нужно. Эта процедура инициализирует структуру значениями по умолчанию.
CREATE_PROCESS_INFO_VERSION нужен на случай изменения структуры в будущем.
Вобщем банальный ООП.

Короче посмотри на System.Diagnostics.Process там все весьма не плохо сделано.

Да это несколько длиннее чем fork но за то нам не нужно решать проблемы которые создает fork, а это очень большой плюс.

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

TC>Я говорил о работе планировщика в Windows, а не про RTOS. Ясен пень, говорить за все ОС невозможно — я могу написать планировщик как мне заблагорассудиться. Мы говорили о Windows на которой крутяться 100 потоков.
Вобщето разговор изначально шол про юникс клоны. После чего плавно перешол на ОС вобще.
TC>А в этой славной ОС планировщик не работает при обработке любого прерывания, а только таймерного.
Если мне не изменяет скалероз работа планировщика в этой ОС вобще не документирована и меняется от версии к версии.
TC>Более того, обработчики прерываний не могут напрямую повлиять на роцесс планировки.
И кто мешает мелкософтам это поменять?
TC>Если им это нужно, они регистрят специальную отложенную процедуру, которая как раз и будет выполнена непосредственно перед плнировкой и может на нее повлиять. Так что голову оставлю при себе с ВАшего позволения .
[голосом мегазлодея]
Не зарекайся... [безумный смех]Муха-ха-ха-ха-ха-ха...[/безумный смех]
[/голосом мегазлодея]

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

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

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

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

Я уже давно понял, что производительность положена на алтарь скорости разрботки. Поэтому и требуются все более и более мощные компы...
Я все жду хотябы прогноза — когдаже перестанут гнать количество, а возьмутся за качество. Но думаю очень нескоро...

WolfHound wrote:
> ДД>Я согласен с тем, что асинхронность рулит не всегда.
> ДД>Но где написано, что он блокирующий? Просто не встречал такой информации.
> Ты мне лучше покажи где написанно что он асинхронный. Или хотябы может
> работать асинхронно.
splice() просто помещает страницы в ядерное пространство, он больше
ничего не делает. Помещение страниц в ядро — очень быстрая операция, так
как просто нужно поправить несколько дескрипторов.

Что дальше с этими страницами будешь делать — твое личное дело. Можешь,
например, натравить на них DMA (который есть асинхронный). А можешь
отдать sendfile'у, который синхронный.

Если это так, то это хорошо. Но вот чтото мне подсказывает, что не так все гладко.

зы В баше создать пару тыщ процессов в крупном скрипте также естесственно.

Sheridan wrote:
> Если это так, то это хорошо. Но вот чтото мне подсказывает, что не так
> все гладко.
Это "что-то" тебе подсказывает неправильно. Тысячи и сотни тысяч
одновременных процессов в Эрланге — это самое обычное дело. Это
все прекрасно работает из-за того, что процессы там легковесные — и на
один системный поток может проецироваться несколько эрланговских процессов.

Этот трюк еще в JRockit для Java применяется.

> зы В баше создать пару тыщ процессов в крупном скрипте также естесственно.
Не одновременно.

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

WH>Да это несколько длиннее чем fork но за то нам не нужно решать проблемы которые создает fork, а это очень большой плюс.

Если форк создает проблемы — не используй форк. В чем проблемы-то?

>> C>Зато Yaws ляжет, если каждому из потоков нужно будет отдать файл
>> C>размером в 10Мб. Просто из-за того, что Apache использует sendfile,
>> C>который работает в режиме ядра.
>> Возможно, не спорю. Но это надо замеры производить или прикручивать
>> sendfile к yaws
C>А не получится прикрутить — он блокирующийся То есть нужно будет
C>создавать пул системных потоков, которые будут выполнять sendfile. Ну в
C>общем, Апач и получится в итоге.

Интересно, в рассылке создатель Yaws ответил следующее:

I'm pretty sure that apache would outperform yaws here — unless
the number of concurrent clients requesting these 10M files
is large — in which case I think yaws would do fine.

Anyway, the test is mostly uninteresting, also building a sendfile
driver and use that for large files in Yaws is a p.o.c — it would probably
take several hours to do ....

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

WH>Ты мне лучше покажи где написанно что он асинхронный. Или хотябы может работать асинхронно.

man 2 sendfile:

ERRORS
EAGAIN Non-blocking I/O has been selected using O_NONBLOCK and write would block.

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

WF>Если форк создает проблемы — не используй форк. В чем проблемы-то?
Я стараюсь... вот только как иначе в юниксах процессы создавать?

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

WF>>Если форк создает проблемы — не используй форк. В чем проблемы-то?
WH>Я стараюсь... вот только как иначе в юниксах процессы создавать?

Ты вообще читаешь, что тебе пишут? Как минимум три варианта назвали — clone, vfork, posix_spawn. Причем последняя функция — POSIX-овая. Почитай на нее ман (в частности, раздел RATIONALE), много интересного найдешь.

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

WH>При том что они тоже клонируются... и начинают страници инвалидировать...

Они не клонируются. После fork()'а в дочернем процессе работает один поток.

WH>Я понял. Просто я не понял какие проблемы склонировать модель? Или ты написал программу в худших традициях фортрана?

Еще раз: проблема была в том, что сторонняя библиотека не предоставляла методов для сохранения и восстановления своего контекста.

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



ДД>>Угу, буду я на embeded-устройстве с 128 Мб ОЗУ и 128 Мб флеш-памяти жабу или .NET ставить. Да еще и майкрософту за винду деньги платить.
WH>1)128 метров памяти болие чем достаточно для того чтобы поднять жабу.
WH>2)Так причем тут винда? Жаба на линуксе работать умеет.
WH>3)Это легко делается везде где есть рантайм рефлексия или еще лучше метапрограммирование.

В эти 128 метров еще должны поместиться иксы с OpenGL, куча спрайтов/текстур и других ресурсов.
Мне начинать изучать джаву или .NET, чтоб тулить их туда, где задача прекрасно решается без них?

ДД>>Обращение к ФС.
WH>Ты хотел сказать обращение к уже загруженному в память бинарному образу. Причем никто его клонировать не будет. Его зашарят.

А если еще не загруженому?

WH>По твоему туже винду совсем идиоты писали?

По-видимому не совсем. В linux'е тоже есть такой sharing, только он не используется там, где без него можно обойтись.

ДД>>Лишние телодвижения для передачи аргументов.
WH>Какой кошмар... берешь любой OORPC хоть COM хоть CORBA и никаких проблем.

И нахрена мне все это, если есть более простые и быстрые способы?

ДД>>Короче, через Ж..
WH>И это говорит любитель форка...

Jedem das seine.

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

WH>CreateProcessInfo processInfo;
WH>InitCreateProcessInfo(&processInfo, CREATE_PROCESS_INFO_VERSION);
WH>processInfo.imageName = "C:\\superPuper.exe";
WH>HANDLE stdIn = InterceptStdStream(&processInfo, STDSTREAM_IN);
WH>HANDLE stdOut = InterceptStdStream(&processInfo, STDSTREAM_OUT);
WH>HANDLE stdErr = InterceptStdStream(&processInfo, STDSTREAM_ERR);
WH>CreateProcess(&processInfo);
WH>

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

И поддерживать все возможные версии? А если их станет слишком много, старые убирать, теряя обратную совместимость?

WH>Вобщем банальный ООП.

Я не сторонник пихания ООП во все подряд.

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

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


А какое переключение не будет?