Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>Это чего, преподносится как что то значимое в общем смысле? Ты же прекрасно понимаешь, что это голимый примитив, никак не демонстрирующий преимуществ динамики.
G>>Ты тред читал? Это ответ на
НС>Читал. Только какой смысл расползаться мыслью по древу?
Я отвечал на зацитированное. Повторил код на мегаязыке, создающий два потока, и, вопреки предположениям, не вспотел. Смысл очень простой — это называется "контрпример".
G>>У тебя еще чего-нибудь?
НС>Ну там в сообщении немного больше было. Но не хочешь отвечать — я не настаиваю.
Да мне не трудно. > И правда, нафига в том же дотнете все эти TPL и Rx с асинками? Написал несколько простеньких хелперов с лямбдами поверх пула потоков и вуаля, все проблемы решены.
Учитывая, что ты при этом не теряешь отладчика в браузере — да, именно так. Вуаля, все проблемы решены. Ну, soft-type checker, вроде того, что есть в Google Closure Compiler еще сильно поможет, да. А в остальном все хорошо.
Re[19]: Гы, а Wolfhound — неосилятор, оказывается.
Здравствуйте, WolfHound, Вы писали:
M>>Что-то мне кажется, что ты противопроставил эти два предложения Ж-\ WH>Ты на самом деле не понимаешь чем поток отличается от таймера с калбеком?
А ты на самом деле не понимаешь, чем настоящий поток WebWorker отличается от этой шняги, которая генерится твоим мегаязыком? А ты убери в примере на мегаязыке ожидания внутри циклов, и убери в моем примере из WorkerThread-ов таймеры, запусти оба, и увидишь.
G>>selective receive. WH>А это ошибка дизайна и ведет к снижению надежности. WH>
WH>The system is dimensioned so that the CPU load is low (say 10 %). Now at some point in time, the backend service takes one second longer than usual to process one particular request. You'd expect that some requests will be delayed (by no more than one second) and that quality of service will return to normal within two seconds, since there is so much spare capacity.
WH>Instead, the following can happen: During the one second outage, requests accumulate in the message queue of the server process. Subsequent gen_server calls take more CPU time than usual because they have to scan the whole message queue to extract replies. As a result, more messages accumulate, and so on.
WH>snowball.erl (attached) simulates all this. It slowly increases the CPU load to 10 %. Then it pauses the backend for one second, and you can see the load rise to 100 % and remain there, although the throughput has fallen dramatically.
WH>Here are several ways to avoid this scenario...
WH> ...
WH> Add a proxy process dedicated to buffering requests from clients and making sure the message queue of the server remains small. This was suggested to me at the erlounge. It is probably the best solution, but it complicates process naming and supervision. And programmers just shouldn't have to wonder whether each server needs a proxy or not.
Never, but never use async messages into a blocking server from the outside world.
С интернетов:
The problem in this scenario is *coupling* too closely the asynchronous selective receive with the backend synchronous service. This is not an uncommon scenario in all kinds of "service-oriented architectures" and the solution, generally, should be the one quoted above.
То есть ВНЕЗАПНО проблема оказалась не в якобы ошибке дизайна (в чем там ошибка? ну, раз так сказал сам WolfHound, она там просто обязана быть, ага), а в ошибке архитектуры приложения.
Любая система, обрабатывающая сообщения медленнее, чем они в нее входят, будет иметь эту проблему.
WH>Здравствуйте, Mamut, Вы писали:
M>>Что-то мне кажется, что ты противопроставил эти два предложения Ж-\ WH>Ты на самом деле не понимаешь чем поток отличается от таймера с калбеком?
Ты на само мделе не видишь в примере Гапертона двух потоков? То, как они между собой общаются — это дело десятое.
Ты на самом деле видишь в примере ur'а два настоящих потока? При том, что они релизованы таймерами и колбеком?
M>>Тебе такое понятия, как «библиотека», знакомо?
M>>Тут спокойно пишется то, что тебе надо в виде библиотеки. WH>Да правда чтоли? WH>Повтори код на UR в виде библиотеки. WH>
WH>fun main () =
WH> buf <- Buffer.create;
WH> let
WH> fun loop prefix delay =
WH> let
WH> fun loop' n =
WH> Buffer.write buf (prefix ^ ": Message #" ^ show n);
WH> sleep delay;//Вот тут у тебя будут большие проблемы
WH> loop' (n + 1)
WH> in
WH> loop'
WH> end
WH> in
WH> return <xml><body onload={spawn (loop "A" 5000 0); spawn (loop "B" 3000 100)}>
WH> <dyn signal={Buffer.render buf}/>
WH> </body></xml>
WH> end
WH>
Предполагаю, что sleep delay там транслируется в yield sleep(delay)
Но я помню, ты слепо веришь в то, что в Ur создаются два настоящих потока, ага Фигня, что Ur транслируется в JS. Значит, ВНЕЗАПНО, это — по сути, всего лишь DSL, транслирующийся в JS. Значит, реализовать это не должно вызывать больших проблем.
A>>То же самое происходит и в коде на Ur, даже более примитивно, поскольку настоящих процессов не создаётся. WH>Там наблюдаются настоящие кооперативные потоки. WH>Из этого следует, что нам не нужно плясать с бубном, чтобы обновлять UI.
Wolfhound, этот код транслируется в голый JavaScript. То есть никакими потоками там и не пахнет.
Для того, чтобы не плясать с бубном при обновлении UI, Ur не нужен. Нужен, например, knockout.js.
Здравствуйте, Mamut, Вы писали:
M>То есть ВНЕЗАПНО проблема оказалась не в якобы ошибке дизайна (в чем там ошибка? ну, раз так сказал сам WolfHound, она там просто обязана быть, ага), а в ошибке архитектуры приложения.
M>Любая система, обрабатывающая сообщения медленнее, чем они в нее входят, будет иметь эту проблему.
ВНЕЗАПНО выяснилось, что ты тоже не умеешь читать.
Там приводится сценарий, в котором система в среднем справляется с нагрузкой с десятикратным запасом.
Но если хоть одно сообщение притормозить, то очередь распухнет и благодаря данной "гениальной" идеи создателей языка система уже не выйдет из ступора. Ибо все время начинает, есть операция "получить сообщение".
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
M>>Тут спокойно пишется то, что тебе надо в виде библиотеки. WH>Да правда чтоли? WH>Повтори код на UR в виде библиотеки.
Не-не-не, не надо никаких sleep-ов никуда втыкать.
Повтори вот этот код Worker-а в "потоке" на своем мегаязыке — без delay-ев.
onmessage = function( a_event ){
var count = 0;
while( true ){
for( var i = 0; i < 10000000000; i ++ ){} // вот тут у тебя будут большие проблемы.
postMessage( a_event.data.prefix + ' ' + count++ );
}
};
Вообще вспотеешь. Ибо, у тебя там никакие не потоки, а дешевая их симуляция. Трюк. Обман. Видимость.
А что до синхронных вызовов — в настоящих потоках WebWorker я совершенно спокойно могу делать AJAX-вызовы синхронно, не переживай. Это работает без каких-либо дополнительных танцев с бубном. Ничего они мне, кроме того потока, не заблокируют.
Здравствуйте, Mamut, Вы писали:
M>Wolfhound, этот код транслируется в голый JavaScript. То есть никакими потоками там и не пахнет.
Читать ты точно не умеешь.
M>Для того, чтобы не плясать с бубном при обновлении UI, Ur не нужен. Нужен, например, knockout.js.
На ур кода всеравно меньше получается.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
M>>Wolfhound, этот код транслируется в голый JavaScript. То есть никакими потоками там и не пахнет. WH>Читать ты точно не умеешь.
Читать что?
Ты даешь ссылку на демонстрацию якобы многопоточности в ur.
Ты хочешь сказать, что ur транслируется не в HTML + Javascript?
Ты хочешь сказать, Ur реализует реальную многопоточность в Javascript? Каким образом?
M>>Для того, чтобы не плясать с бубном при обновлении UI, Ur не нужен. Нужен, например, knockout.js. WH>На ур кода всеравно меньше получается.
Какая разница? Реальной многопоточностью там и не пахнет. При желании к JS можно прикрутить coffescript и получить совсем мало кода.
M>>То есть ВНЕЗАПНО проблема оказалась не в якобы ошибке дизайна (в чем там ошибка? ну, раз так сказал сам WolfHound, она там просто обязана быть, ага), а в ошибке архитектуры приложения.
M>>Любая система, обрабатывающая сообщения медленнее, чем они в нее входят, будет иметь эту проблему. WH>ВНЕЗАПНО выяснилось, что ты тоже не умеешь читать. WH>Там приводится сценарий, в котором система в среднем справляется с нагрузкой с десятикратным запасом. WH>Но если хоть одно сообщение притормозить, то очередь распухнет и благодаря данной "гениальной" идеи создателей языка система уже не выйдет из ступора. Ибо все время начинает, есть операция "получить сообщение".
ВНЕЗАПНО выяснилось, что читать не умеешь ты.
В систему втекает поток сообщений, который обрабатывается, по сути, блокирующим сервером:
the backend service takes one second longer than usual to process one particular request
То есть тормозит не сообщение, не очередь, а обработка этой очереди. Банальный (D)DOS, из которого ты делаешь максимально неверные далеко идущие выводы.
Я боюсь даже попросить тебя предоставить правильный вариант на замену selective receive
Здравствуйте, Gaperton, Вы писали:
G>Не-не-не, не надо никаких sleep-ов никуда втыкать. G>Повтори вот этот код Worker-а в "потоке" на своем мегаязыке — без delay-ев.
Мне еще сколько десятков раз написать, что потоки кооперативные?
С другой стороны это дает возможность спокойно работать с данными без плясок с бубном.
Кстати надеюсь, ты понимаешь, что ничто не мешает скомпилировать этот код так чтобы не было этой проблемы... вспомни, что делает ерланг и скажи, почему это не сможет сделать ур...
G>А что до синхронных вызовов — в настоящих потоках WebWorker я совершенно спокойно могу делать AJAX-вызовы синхронно, не переживай. Это работает без каких-либо дополнительных танцев с бубном. Ничего они мне, кроме того потока, не заблокируют.
Не переживай ты так. Вызовы серверного кода в ur все "синхронные".
Причем везде.
И при этом ничего не тормозиться.
Магия, да и только...
Повторю еще раз мне все равно во что ур это перепишет.
Я прекрасно понимаю, что там получается. Мне важна модель исполнения самого ур.
G>Этого, ты, разумеется, тоже не знал, да?
Да я прекрасно понимаю, что такое этот твой воркер.
Похоже, что даже лучше чем ты.
Кстати ты не забыл с чего разговор начался?
WH>Может ты покажешь задачу где нужна динамическая типизация?
Я тебе ее показываю. Это работа с отрисовкой веб-страницы и сетью в браузере.
Так зачем тут динамическая типизация то? Если насквозь статический ур с этим справляется лучше, чем жабаскрипт не смотря на мегатонны библиотек?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Mamut, Вы писали:
M>То есть тормозит не сообщение, не очередь, а обработка этой очереди. Банальный (D)DOS, из которого ты делаешь максимально неверные далеко идущие выводы.
Ты не то выделил. Вот так правильно:
the backend service takes one second longer than usual to process one particular request
Те один запрос протормозил и приехали.
Вместо того чтобы быстренько разобрать накопившийся хвост система будет тупить на выборке сообщений из очереди.
M>Я боюсь даже попросить тебя предоставить правильный вариант на замену selective receive
Обычная очередь такой проблемы не имеет. Ибо получение сообщения O(1) гарантировано. В то время как selective receive O(N) в общем случае.
И как следствие мы попадаем на O(N^2) чтобы прочитать всю очередь.
Что собственно все и убило.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
M>>То есть тормозит не сообщение, не очередь, а обработка этой очереди. Банальный (D)DOS, из которого ты делаешь максимально неверные далеко идущие выводы. WH>Ты не то выделил. Вот так правильно: WH>
WH>the backend service takes one second longer than usual to process one particular request
WH>Те один запрос протормозил и приехали. WH>Вместо того чтобы быстренько разобрать накопившийся хвост система будет тупить на выборке сообщений из очереди.
Каким образом система будет разбирать этот хвост по твоему?
M>>Я боюсь даже попросить тебя предоставить правильный вариант на замену selective receive WH>Обычная очередь такой проблемы не имеет. Ибо получение сообщения O(1) гарантировано. В то время как selective receive O(N) в общем случае. WH>И как следствие мы попадаем на O(N^2) чтобы прочитать всю очередь. WH>Что собственно все и убило.
ВНЕЗПНО в рассылке сказали так, по сути, и сделать, но ты их всех считаешь идиотами, и создателями языка — в том числе.
Ты хотя бы вообще в курсе, что такое selective recieve и зачем он нужен?
Здравствуйте, Mamut, Вы писали:
M>Каким образом система будет разбирать этот хвост по твоему?
У системы в среднем десятикратный запас по производительности.
Повторю еще раз ДЕСЯТИКРАТНЫЙ!!!!!!!!!
Так что если без тормозов при получении сообщения, то все будет просто летать.
И очередь разберется за 100-200 миллисекунд.
M>Ты хотя бы вообще в курсе, что такое selective recieve и зачем он нужен?
Чтобы любой всплеск нагрузки убивал систему.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
G>>Не-не-не, не надо никаких sleep-ов никуда втыкать. G>>Повтори вот этот код Worker-а в "потоке" на своем мегаязыке — без delay-ев. WH>Мне еще сколько десятков раз написать, что потоки кооперативные?
Там нет потоков вообще. Там есть только setTimeout и прочая братия.
WH>С другой стороны это дает возможность спокойно работать с данными без плясок с бубном.
В JS тоже можно так работать knockout.js и прочая.
WH>Кстати надеюсь, ты понимаешь, что ничто не мешает скомпилировать этот код так чтобы не было этой проблемы... вспомни, что делает ерланг и скажи, почему это не сможет сделать ур...
Не сможет, потому что ur (ну или то, что в примерах) компилируется в JS.
G>>А что до синхронных вызовов — в настоящих потоках WebWorker я совершенно спокойно могу делать AJAX-вызовы синхронно, не переживай. Это работает без каких-либо дополнительных танцев с бубном. Ничего они мне, кроме того потока, не заблокируют. WH>Не переживай ты так. Вызовы серверного кода в ur все "синхронные". WH>Причем везде. WH>И при этом ничего не тормозиться. WH>Магия, да и только...
function requestUri(xhr, uri, needsSig) {
if (unloading)
return;
xhr.open("POST", uri, true);
Я боюсь тебя разочаровать, но этот параметр означает асинхронный вызов
WH>Повторю еще раз мне все равно во что ур это перепишет. WH>Я прекрасно понимаю, что там получается.
Ага. как ты там говорил. «Настоящие потоки». Сразу видно, как ты это понимаешь, ага
WH>Мне важна модель исполнения самого ур.
Ну да, сферовакуумная модель в вакууме.
Gaperton показал тебе реальную многопоточность в JS безо всяких моделей исполнения.
G>>Этого, ты, разумеется, тоже не знал, да? WH>Да я прекрасно понимаю, что такое этот твой воркер. WH>Похоже, что даже лучше чем ты.
WH>Кстати ты не забыл с чего разговор начался? WH>
WH>>Может ты покажешь задачу где нужна динамическая типизация?
WH>Я тебе ее показываю. Это работа с отрисовкой веб-страницы и сетью в браузере.
WH>Так зачем тут динамическая типизация то? Если насквозь статический ур с этим справляется лучше, чем жабаскрипт не смотря на мегатонны библиотек?
Ага. Аргументы закончились, внезпно надо восстанавливать контекст, который ты сам и забыл со своими примерами. «А вот это вообще делать вспотеешь: http://www.impredicative.com/ur/demo/threads.html», видимо, Гапертон написал...
M>>Каким образом система будет разбирать этот хвост по твоему? WH>У системы в среднем десятикратный запас по производительности. WH>Повторю еще раз ДЕСЯТИКРАТНЫЙ!!!!!!!!! WH>Так что если без тормозов при получении сообщения, то все будет просто летать. WH>И очередь разберется за 100-200 миллисекунд.
И? Берешь в руки любую очередь и тормозишь с обработкой сообщения. У тебя будет точно такая же проблема Банальный, блин, DOS.
M>>Ты хотя бы вообще в курсе, что такое selective recieve и зачем он нужен? WH>Чтобы любой всплеск нагрузки убивал систему.
Здравствуйте, Mamut, Вы писали:
M>И? Берешь в руки любую очередь и тормозишь с обработкой сообщения. У тебя будет точно такая же проблема Банальный, блин, DOS.
Это не ДОС, а кратковременный всплеск. Обычная ситуация.
При использовании нормальной очереди рассосётся само за 100-200 миллисекунд.
WH>>Чтобы любой всплеск нагрузки убивал систему. M>Угу, так и запишем: не знает, и знать не хочет.
А нахрена мне линейный алгоритм, если я тоже самое могу сделать константным?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
A>>То есть берём любую обёртку на JavaScript, и задумываемся, зачем нам Ur? Кстати, на какой бы уровень ты не перешёл, не будет настоящих потоков. WH>1)За тем чтобы писать еще меньше кода. Ибо все эти обертки заставляют писать кучу мусора.
Зависит от обёртки. Ведь Ur тоже всего лишь обёртка.
WH>2)За тем чтобы компилятор ловил ошибки. Это ты вообще никакими обертками не сделаешь.
. Куда уж проще. 
