Комментарии 129
Корутины? А как бы вы перевели routines? А coworkers?
Хороший вопрос — я не нашел пока адекватного перевода. В немногочисленных русскоязычных статьях на эту тему используется термин «корутин». Если вы предложите адекватный русскоязычный термин, то я большим удовольствием отредактирую перевод.
«Django или Ruby on Rails, возможно два самых многообещающих веб-фреймворка, появившихся за последние два года» — тут какая-то ошибка; точно не 2 года.
Rails с 2004-го вроде, про джангу не знаю
Да вообще такое ощущение, что статья года из 2005 )
Тогда как раз не было еще Stackless python с зелеными тредами, не существовало гринлетов, не были написаны фреймворки которые прозрачно делают ввод-вывод асинхронным, не было PyPy со встроенными зелеными тредами.
А сейчас, привет 2010 — автор понял что зеленые треды это хорошо.
Тогда как раз не было еще Stackless python с зелеными тредами, не существовало гринлетов, не были написаны фреймворки которые прозрачно делают ввод-вывод асинхронным, не было PyPy со встроенными зелеными тредами.
А сейчас, привет 2010 — автор понял что зеленые треды это хорошо.
Да, спасибо. Ошибка в переводе. А статья от февраля 2010.
Основная проблема в том, что для написания программ в асинхронном стиле надо мыслить по другому.
Люди с трудом усваивают, что нельзя сделать
Еще многие люди считают, что раз это (например) ДжаваСкрипт и несинхронно, то ничего кроме процедурщины уже не подходит. Немножко иначе выглядя все те же принципы остаются.
Бороться с вложеностью можно стандартными для синхронного программирования способами, например ООП. Если нам надо получить отдельным запросом топик и отдельным — комменты, то можно очень красиво сделать это так:
Методы разбиты на небольшие куски, красиво сгруппированы, вложенность — минимальная. Код читается не лучше, чем аналогичный синхронный.
Люди с трудом усваивают, что нельзя сделать
var foo = ajax('example.com');, а уж целое асинхроноое приложение — это просто ужас.Еще многие люди считают, что раз это (например) ДжаваСкрипт и несинхронно, то ничего кроме процедурщины уже не подходит. Немножко иначе выглядя все те же принципы остаются.
Бороться с вложеностью можно стандартными для синхронного программирования способами, например ООП. Если нам надо получить отдельным запросом топик и отдельным — комменты, то можно очень красиво сделать это так:
// обработка у нас будет выглядеть как-то так:
new Topic(id).get(function (data) {
render(data.article, data.comments);
});
// Сам класс прост:
var Topic = function (conn, id) {
this.conn = conn;
this.id = id;
};
Topic.prototype = {
// Получены и статья и комменты:
get : function (fn) {
var data = {};
var set = function (key, value) {
data[key] = value;
if ('article' in data && 'comments' in data) fn(data);
};
this.getArticle(function (article) {
set('article', article);
});
this.getComments(function (comments) {
set('comments', comments);
});
},
// получение статьи из БД:
getArticle(fn) {
this.conn.query(qArticles, function (err, res) {
if (err) throw err;
res.fetchAll(function (err, rows) {
if (err) throw err;
fn(rows.length ? rows[0] || null);
});
});
},
// Получение комментов из БД:
getComments(fn) {
this.conn.query(qComments, function (err, res) {
if (err) throw err;
res.fetchAll(function (err, rows) {
if (err) throw err;
fn(rows);
});
});
},
};
Методы разбиты на небольшие куски, красиво сгруппированы, вложенность — минимальная. Код читается не лучше, чем аналогичный синхронный.
«Код читается не лучше, чем» => «Код читается не хуже, чем»
Огромнешее спасибо за пример!
Только ошибки лучше отдавать в колбэк, а не делать throw. Иначе их не поймать будет уровнем выше.
Программисты меня, конечно, не поддержат, оцениваю как менеджер:
что дешевле: поддерживать сложный код (это требует больших временных затрат на написание и тестирование и сложнее к тому же, новички-программисты могут не справиться, а значит, такое решение будет дороже + оно и не обкатанное ещё нигде особо) или просто купить ещё несколько серверов в hetzner? :-)
Мне кажется, что такое будет эффективно только на проектах масштаба яндекса, твиттера, вконтакте и подобных :-)
Для обычных сайтов экономически целесообразнее использовать те технологии, что есть сейчас… Потому что проще…
что дешевле: поддерживать сложный код (это требует больших временных затрат на написание и тестирование и сложнее к тому же, новички-программисты могут не справиться, а значит, такое решение будет дороже + оно и не обкатанное ещё нигде особо) или просто купить ещё несколько серверов в hetzner? :-)
Мне кажется, что такое будет эффективно только на проектах масштаба яндекса, твиттера, вконтакте и подобных :-)
Для обычных сайтов экономически целесообразнее использовать те технологии, что есть сейчас… Потому что проще…
На мелких задачах оба подхода будут приблизительно однаково быстро программироваться и приблизительно одинаково быстро выполнятся.
На крупных задачах оба подхода будут долго програмится, но асинхронный будет быстрее работать
Плюс дело в опыте
На крупных задачах оба подхода будут долго програмится, но асинхронный будет быстрее работать
Плюс дело в опыте
На мелких задачах, да )) jQuery ну ооочень синхронный.
Ха-ха! Как раз в тему твит Джоела Спольски:
"@spolsky: Digg: 200MM page views, 500 servers. Stack Overflow: 60MM page views, 5 servers. What am I missing? "
"@spolsky: Digg: 200MM page views, 500 servers. Stack Overflow: 60MM page views, 5 servers. What am I missing? "
Ссылка в тексте на node.js, это куда?
Видимо очепятка, должно быть так
Вы забыли про твистед в питоне — очень замечательный пример, я тоже сначало смотрел с круглыми глазами на него.
«Давайте, наконец, слезем с кресел-каталок, и пойдем с костылями! Да, на кресле конечно больше удобств, зато с костылями больше шансов по настоящему...» — тут подставьте своё
Почему даже в 2010 году мы пишем программы программы, полагающиеся на синхронное программирование?
Повторяется слово «программы».
Повторяется слово «программы».
http:/tsya.ru
НЛО прилетело и опубликовало эту надпись здесь
хм. а по мне синхронный код проще.
помню разбирались как-то с одним асинхронным проектом. проблема была с разной производительностью у модулей проекта.
Примерно так — из сокета принимается сообщение, для него выделяется память и этот объект ставится в очередь. Другой модуль выбирал из этой очереди и что-то рисовал на экране (и довольно медленно). Получалось, что на быстрых сетях очередь сообщений могла расти в пиках очень быстро, а разгружалась медленно. Появлялся эффект «резиновой отвертки» — отображение информации запаздывает несмотря на жуткий трафик.
В синхронной системе происходит автоматическая регулирование — прием данных в темпе рисования, и не более того.
Хотя конечно и асинхронный и синхронный код всегда можно написать плохо.
помню разбирались как-то с одним асинхронным проектом. проблема была с разной производительностью у модулей проекта.
Примерно так — из сокета принимается сообщение, для него выделяется память и этот объект ставится в очередь. Другой модуль выбирал из этой очереди и что-то рисовал на экране (и довольно медленно). Получалось, что на быстрых сетях очередь сообщений могла расти в пиках очень быстро, а разгружалась медленно. Появлялся эффект «резиновой отвертки» — отображение информации запаздывает несмотря на жуткий трафик.
В синхронной системе происходит автоматическая регулирование — прием данных в темпе рисования, и не более того.
Хотя конечно и асинхронный и синхронный код всегда можно написать плохо.
Полагаю в таком случае имело смысл совмещать синхронный и асинхронный подход?
Ничто не мешает нам заменить часть асинхронного кода синхронным? Ну например, заставив после асинхронного вызова ожидать программу.
Ничто не мешает нам заменить часть асинхронного кода синхронным? Ну например, заставив после асинхронного вызова ожидать программу.
Совет автору: а вы абсолютно все пакеты пришедших данных пытались там выводить на графике? Очередь сообщений надо бы разгружать сразу: если вам нужны данные «на потом», то лучше сразу подсчитать среднее значение (которое пойдёт на график).
Вообще, задача очень нетривиальная, см. TCP throttling.
И, простите, «в лоб» не решаемая — получили то, что получили :-)
Вообще, задача очень нетривиальная, см. TCP throttling.
И, простите, «в лоб» не решаемая — получили то, что получили :-)
В питоне нет twister'a, есть twisted
Не Twister, а Twisted. И он тормоз.
Не раскрыта тема Stackless Python. Erlang, Ocaml/Lwt, Haskell/ForkIO и т.п
Есть примеры кода с «синхронным» подходом, но не вижу асинхронного кода.
Так где про асинхронность?
Не раскрыта тема Stackless Python. Erlang, Ocaml/Lwt, Haskell/ForkIO и т.п
Есть примеры кода с «синхронным» подходом, но не вижу асинхронного кода.
Так где про асинхронность?
На самом деле, любое многопоточное программирование — это complexity booster. Какие бы прекрасные возможности во фреймворке для него не предоставлялись, в реальности там все равно будут проблемы с race conditions, одновременным доступом и так далее.
Поэтому одно дело, когда мы говорим про конкретную ситуацию — в частности, вызов нескольких операций с клиента и отрисовка по мере получения результата, это типовая задача для асинхронности, здесь проблем не очень много, а выигрыш, наоборот, большой (хотя мне вот сейчас в одной задаче регулярно нужно, чтобы вызов на сервер вел себя исключительно синхронно).
И другое дело, когда мы говорим, что «разработчики должны думать про свой код в терминах коллбеков и асинхронности», что далеко не всегда оправданно, потому что проследить глазами цепочку выполнения такого кода, все его зависимости и так далее — очень сложно.
Что Фаулер, что Эспозито/Сальтарелло предостерегают от использования многопоточности без четкого предварительного планирования. Банальный пример: один цикл request/response на веб-сервере почти всегда можно и нужно писать синхронно (но при этом ориентироваться на stateless-модель, чтобы он легко масштабировался на любое количество выполнений); исключения составляют множественные длинные и независимые друг от друга операции (читать два файла параллельно, если они в одном хранилище, скорее всего, неопраданно; читать информацию с двух разных сайтов — скорее всего, имеет смысл).
Поэтому одно дело, когда мы говорим про конкретную ситуацию — в частности, вызов нескольких операций с клиента и отрисовка по мере получения результата, это типовая задача для асинхронности, здесь проблем не очень много, а выигрыш, наоборот, большой (хотя мне вот сейчас в одной задаче регулярно нужно, чтобы вызов на сервер вел себя исключительно синхронно).
И другое дело, когда мы говорим, что «разработчики должны думать про свой код в терминах коллбеков и асинхронности», что далеко не всегда оправданно, потому что проследить глазами цепочку выполнения такого кода, все его зависимости и так далее — очень сложно.
Что Фаулер, что Эспозито/Сальтарелло предостерегают от использования многопоточности без четкого предварительного планирования. Банальный пример: один цикл request/response на веб-сервере почти всегда можно и нужно писать синхронно (но при этом ориентироваться на stateless-модель, чтобы он легко масштабировался на любое количество выполнений); исключения составляют множественные длинные и независимые друг от друга операции (читать два файла параллельно, если они в одном хранилище, скорее всего, неопраданно; читать информацию с двух разных сайтов — скорее всего, имеет смысл).
НЛО прилетело и опубликовало эту надпись здесь
Асинхронности без многопоточности не бывает.
Если вы ее не видите (т.е., для вас ее спрятала платформа), вам повезло. Но за кадром это всегда многопоточность. И чем больше выигрыша вы хотите получить от использования асинхронности, тем ближе к реальности (многопоточности) вам надо быть.
Если вы ее не видите (т.е., для вас ее спрятала платформа), вам повезло. Но за кадром это всегда многопоточность. И чем больше выигрыша вы хотите получить от использования асинхронности, тем ближе к реальности (многопоточности) вам надо быть.
:-) ну, ну, ну…
асинхронность без многопоточности — это один цикл и действия, разбитые во времени.
Вполне себе бывает.
И именно здесь есть среднее звено парадигмы мышления. Т.е., сначала мы пишем последовательный («синхронный» :-) код. Затем учимся разбивать код на независимые от последовательности выполнения группы («асинхронный» код). А потом уже работаем с многопоточной обработкой — но опыт с асинхронным кодом идёт нам на пользу.
асинхронность без многопоточности — это один цикл и действия, разбитые во времени.
Вполне себе бывает.
И именно здесь есть среднее звено парадигмы мышления. Т.е., сначала мы пишем последовательный («синхронный» :-) код. Затем учимся разбивать код на независимые от последовательности выполнения группы («асинхронный» код). А потом уже работаем с многопоточной обработкой — но опыт с асинхронным кодом идёт нам на пользу.
Возможно подразумевают эмуляцию асинхронности через многопоточность например в драйвере MySQL для библиотек написанных в синхронном стиле. А так да, все в одном потоке.
Кстати, как асинхронные задачи работают на многопроцессорных машинах?
Кстати, как асинхронные задачи работают на многопроцессорных машинах?
Как-как…
Запускаешь несколько процессов, по одному на ядро процессора, каждый из которых работает в собственном цикле.
Или так (если не о питоне речь, где GIL путает карты): один процесс работает в асинхронном режиме (принимает запросы ), обработку же отправляет в отдельные треды на соседние ядра/процессоры.
Запускаешь несколько процессов, по одному на ядро процессора, каждый из которых работает в собственном цикле.
Или так (если не о питоне речь, где GIL путает карты): один процесс работает в асинхронном режиме (принимает запросы ), обработку же отправляет в отдельные треды на соседние ядра/процессоры.
«асинхронность без многопоточности — это один цикл и действия, разбитые во времени.»
А можно пример для тупых?
А можно пример для тупых?
Ну почему же для тупых? Я, наверное, неясно выразился просто.
Цикл, как правило, подразумевает наличие некого фреймворка (возможно, и самописного), в котором этот самый цикл обычно вертится.
Т.е., вместо операций «скачать» пишем операции «начать качать» и «обрабатывать в таком то-месте, когда скачается». Фреймворк же внутри может «poll'ить» сетку на предмет входящих данных.
Проще GUI'ёвый пример, когда нужно развязать GUI, логику и обработку. Одного потока часто будет достаточно, если обработка разбита на маленькие куски, каждый из которых делает маленькую часть работы, а в промежутках идёт работа с GUI.
Цикл, коллбэки, маленькие операции — думаю, этого достаточно для реализации асинхронности без многопоточности.
Цикл, как правило, подразумевает наличие некого фреймворка (возможно, и самописного), в котором этот самый цикл обычно вертится.
Т.е., вместо операций «скачать» пишем операции «начать качать» и «обрабатывать в таком то-месте, когда скачается». Фреймворк же внутри может «poll'ить» сетку на предмет входящих данных.
Проще GUI'ёвый пример, когда нужно развязать GUI, логику и обработку. Одного потока часто будет достаточно, если обработка разбита на маленькие куски, каждый из которых делает маленькую часть работы, а в промежутках идёт работа с GUI.
Цикл, коллбэки, маленькие операции — думаю, этого достаточно для реализации асинхронности без многопоточности.
«Одного потока часто будет достаточно, если обработка разбита на маленькие куски, каждый из которых делает маленькую часть работы, а в промежутках идёт работа с GUI.»
Угу. Попробуйте «разбить на маленькие куски» обращение в БД.
Угу. Попробуйте «разбить на маленькие куски» обращение в БД.
При желании можно и нужно — вопрос в том, чем программа должна заниматься, пока идёт SQL-запрос. Если нужно делать что-то ещё, или сохранить отзывчивость GUI'я — то нужно, чтобы интерфейс доступа к БД поддерживал асинхронные запросы. Обычно так оно и есть. Так в чём же проблема (или задача)?
«нужно, чтобы интерфейс доступа к БД поддерживал асинхронные запросы.»
Угу. Где они выполняются? Неужели в том же потоке, что и ваш код?
Угу. Где они выполняются? Неужели в том же потоке, что и ваш код?
Можно и в том же потоке, если у вас что-нибудь вроде SQLite. Можно и жёсткий диск читать асинхронно, по кусочку заполняя оперативку. Вот представьте, не было бы у вас операционки, не было бы готового движка БД. Например, при программировании какого-нибудь вычурного PLC-контроллера, в котором даже прерываний нет, и флеш-память можно читать непосредственно процессором, безо всякого там DMA и т.п.
Можно там асинхронный код написать, да, только он и будет нормально работать.
Прошу прощения за такой сверхъестественный пример.
Можно там асинхронный код написать, да, только он и будет нормально работать.
Прошу прощения за такой сверхъестественный пример.
«вот представьте, не было бы у вас операционки»
Неинтересно. Я уже снизу написал, что можной сделать полностью свой шедулер процессорного времени, только он будет синхронный неизбежно.
Как бы, вопрос терминологии.
Асинхронность — это именно возможность плюнуть куда-то _длинную_ задачу и не думать о том, как дробить ее на короткие.
Неинтересно. Я уже снизу написал, что можной сделать полностью свой шедулер процессорного времени, только он будет синхронный неизбежно.
Как бы, вопрос терминологии.
Асинхронность — это именно возможность плюнуть куда-то _длинную_ задачу и не думать о том, как дробить ее на короткие.
Под однопоточностью имеется в виду, что ваш асинхронный код никогда не будет выполнятся в нескольких потоках. Сторонние библиотеки, разумеется, в другом потоке работают.
Два асинхронных бесконечных цикла.
(function() {
alert(1);
setTimeout(arguments.callee, 5000);
})();
(function() {
alert(2);
setTimeout(arguments.callee, 3000);
})();
А зачем оно (помимо анноя бедного пользователя, загрузившего этот код)?
Ага. Теперь скажите мне, кто обеспечивает работу функции setTimeout? Неужели правда тот же поток, в котором выполняется alert()?
Впрочем, рекомендую задуматься не над таймаутами, а над вещами типа «получить ответ от сервера». Они тоже выполняются в том же потоке, что и js-код?
Следующий шаг размышлений: преположим, у вас есть два реквеста, по завершению которых вы апдейтите два разных места на экране. Если реквесты завершились в одно и то же время, а апдейты идут долго, они будут идти параллельно или последовательно?
Впрочем, рекомендую задуматься не над таймаутами, а над вещами типа «получить ответ от сервера». Они тоже выполняются в том же потоке, что и js-код?
Следующий шаг размышлений: преположим, у вас есть два реквеста, по завершению которых вы апдейтите два разных места на экране. Если реквесты завершились в одно и то же время, а апдейты идут долго, они будут идти параллельно или последовательно?
Да, callback setTimeout'а выполняется в том же потоке, что и основной скрипт. Да, ответы от сервера тоже все выполняются в одном потоке строго по очереди. И да, места на экране тоже будут апдейтиться по очереди.
Именно поэтому при написании асинхронных скриптов (я про JS сейчас в основном, на других не писал) нельзя допускать, чтобы какой-то синхронный блок долго выполнялся, зависнет всё. В браузерном JS это легко наблюдается зависанием браузера, т.к. пока выполняется JS даже браузер ничего не делает, не то что какие-то другие потоки.
Именно поэтому при написании асинхронных скриптов (я про JS сейчас в основном, на других не писал) нельзя допускать, чтобы какой-то синхронный блок долго выполнялся, зависнет всё. В браузерном JS это легко наблюдается зависанием браузера, т.к. пока выполняется JS даже браузер ничего не делает, не то что какие-то другие потоки.
«Да, callback setTimeout'а выполняется в том же потоке, что и основной скрипт.»
Не коллбек. Само ожидание таймаута.
«Да, ответы от сервера тоже все выполняются в одном потоке строго по очереди.»
Не ответы от сервера, а _получение_ ответа.
Понимаете, я про это и говорю: у вас есть фреймворк (js-машина), которая дает вам асинхронность без необходимости явно работать с потоками. И она же дает вам сериализацию (строго последовательное выполнение) событий без вашего участия. Но единственный способ, которым это можно сделать (точнее, осмысленно делать на современных многопоточных ОС) — это несколько потоков. В одном работает браузер, в другом — компонент, отвечающий за http requests, и так далее. Иначе вы бы просто не смогли положить запрос к серверу на асинхронное выполнение и продолжить что-то делать.
Не коллбек. Само ожидание таймаута.
«Да, ответы от сервера тоже все выполняются в одном потоке строго по очереди.»
Не ответы от сервера, а _получение_ ответа.
Понимаете, я про это и говорю: у вас есть фреймворк (js-машина), которая дает вам асинхронность без необходимости явно работать с потоками. И она же дает вам сериализацию (строго последовательное выполнение) событий без вашего участия. Но единственный способ, которым это можно сделать (точнее, осмысленно делать на современных многопоточных ОС) — это несколько потоков. В одном работает браузер, в другом — компонент, отвечающий за http requests, и так далее. Иначе вы бы просто не смогли положить запрос к серверу на асинхронное выполнение и продолжить что-то делать.
Да, я уже понял, что вы пытаетесь доказать. Это всё понятно, с этим никто не спорит.
Профит-то в том, что вся эта многопоточность, она скрыта и отлажена, за неё волноваться не надо. Ваш же код выполняется всегда строго по очереди и никаких конфликтов, свойственных многопоточности, у него быть не может.
Профит-то в том, что вся эта многопоточность, она скрыта и отлажена, за неё волноваться не надо. Ваш же код выполняется всегда строго по очереди и никаких конфликтов, свойственных многопоточности, у него быть не может.
НЛО прилетело и опубликовало эту надпись здесь
«После регистрации ЦПУ вообще не делает никаких действий, связанных с „_получение_ ответа“
То есть отсылка http request на сервер (на пару мегабайт), а потом получение оттуда ответа (тоже на пару мегабайт, кусочками) и складывание этого ответа в один объект, понятный js, происходит б-жественной силой?
То есть отсылка http request на сервер (на пару мегабайт), а потом получение оттуда ответа (тоже на пару мегабайт, кусочками) и складывание этого ответа в один объект, понятный js, происходит б-жественной силой?
По поводу последнего с апдейтами — последовательно, кто первый — как карта ляжет. Речь же идет о javascript, верно?
На java так:
Выглядит страшновато, но это потому, что в Java нет анонимных функций, а есть анонимные классы. Ждём 7-й версии или пишем то же самое на С# и будет щасте. Тем более, что пример ужасно примитивный. На работе я строю тяжёлые отчёты примерно по такому же механизму. Во только task у меня реализует расширенный Runnable, который умеет уведомлять о состоянии генератора отчёта (прогресс + текущая выполняемая операция). А реализую я не непосредственно свой интерфейс, а свой же абстрактный класс, где определены protected методы reportProgress и reportActivity, в которых и дёргается SwingUtils.invokeLater. Так что получается, я пишу тот же последовательный код, в котором местами дёргаются reportProgress и reportActivity. А юзер не ждёт, пока программа выйдёт из цикла и начнёт реагировать, а видит гламурное окошко с прогрессбаром. Так что всем хорошо.
Ну и наконец, замечу, что однажды мне пришлось писать веб-морду для некоего XML-RPC сервиса (нужно было просто последовательно дёрнуть 2-3 удалённых метода) и толстого клиента для него же. Так вот оказалось, что JS сильно проиграл в выразительности Java за счёт отсутствия поддержки многопоточности.
Runnable task = new Runnable() {
public void run() {
while (true) {
try {
SwingUtils.invokeLater(new Runnable() {
public void run() {
JOptionPane.showMessageDialog(null, "1");
}
});
Thread.sleep(5000);
} catch (InterruptedException ex) {
break;
}
}
}
};
new Thread(task).start();Выглядит страшновато, но это потому, что в Java нет анонимных функций, а есть анонимные классы. Ждём 7-й версии или пишем то же самое на С# и будет щасте. Тем более, что пример ужасно примитивный. На работе я строю тяжёлые отчёты примерно по такому же механизму. Во только task у меня реализует расширенный Runnable, который умеет уведомлять о состоянии генератора отчёта (прогресс + текущая выполняемая операция). А реализую я не непосредственно свой интерфейс, а свой же абстрактный класс, где определены protected методы reportProgress и reportActivity, в которых и дёргается SwingUtils.invokeLater. Так что получается, я пишу тот же последовательный код, в котором местами дёргаются reportProgress и reportActivity. А юзер не ждёт, пока программа выйдёт из цикла и начнёт реагировать, а видит гламурное окошко с прогрессбаром. Так что всем хорошо.
Ну и наконец, замечу, что однажды мне пришлось писать веб-морду для некоего XML-RPC сервиса (нужно было просто последовательно дёрнуть 2-3 удалённых метода) и толстого клиента для него же. Так вот оказалось, что JS сильно проиграл в выразительности Java за счёт отсутствия поддержки многопоточности.
НЛО прилетело и опубликовало эту надпись здесь
Ваше объяснение мне понравилось. Просто и понятно.
Угу. Вот только сама программа, в которой работает event-loop, внутри синхронна. Асинхронна она только с точки зрения внешнего пользователя, который что-то положил в очередь, а через некое неизвестное время забрал. Беда в том, что чтобы это работало, выполнение пользователя не должно зависеть от выполнения очереди сообщений, а, значит, они сидят в разных потоках.
(ну или у вас написан собственный шедулер задач, который выполняет ту же работу, что и шедулинг процессорного времени; все помнят, что на одноядерной машине многопоточность мнима?)
(ну или у вас написан собственный шедулер задач, который выполняет ту же работу, что и шедулинг процессорного времени; все помнят, что на одноядерной машине многопоточность мнима?)
Э. Чуть докопаюсь к последнему абзацу. Вообще говоря, разве http-серверы — не редкая ли область, где с успехом используется асинхронная модель на неблокирующих сокетах? :) И часто — в симбиозе с многопоточной моделью?
Как раз таки request/response очень просто реализовать.
Сложности начинаются, когда появляется хитрый поток исполнения, с кучей условных ветвлений, сугубо синхронным кодом и так далее.
Как раз таки request/response очень просто реализовать.
Сложности начинаются, когда появляется хитрый поток исполнения, с кучей условных ветвлений, сугубо синхронным кодом и так далее.
«Как раз таки request/response очень просто реализовать. „
Вопрос только в том, зачем, если респонс все равно имеет смысл только целиком.
Вы, собственно, путаете http-серверы, которые заведомо многопоточны, и приложения, которые на них крутятся. Вот вторые должны писаться максимально однопоточно.
Вопрос только в том, зачем, если респонс все равно имеет смысл только целиком.
Вы, собственно, путаете http-серверы, которые заведомо многопоточны, и приложения, которые на них крутятся. Вот вторые должны писаться максимально однопоточно.
Что значит «заведомо многопоточны»? tornado или twisted.web (или как там называется их сервер) вам в пример :) Скорее уж «традиционно многопоточны», но есть достаточно популярные альтернативы.
А приложения — эт, конечно, да. Я за однопоточность. И асинхронность. Только за асинхронность однажды в будущем, когда научимся толково ее делать. Пока это все — размышления, реально делать ее никто не умеет, как верно заметил автор статьи.
А приложения — эт, конечно, да. Я за однопоточность. И асинхронность. Только за асинхронность однажды в будущем, когда научимся толково ее делать. Пока это все — размышления, реально делать ее никто не умеет, как верно заметил автор статьи.
Да, я ошибся, «традиционно многопоточны».
«Пока это все — размышления, реально делать ее никто не умеет, как верно заметил автор статьи.»
А вот здесь вы повторяете мою ошибку. Почему никто не умеет? Платформы уже умеют. И некоторые люди, как следствие, тоже.
«Пока это все — размышления, реально делать ее никто не умеет, как верно заметил автор статьи.»
А вот здесь вы повторяете мою ошибку. Почему никто не умеет? Платформы уже умеют. И некоторые люди, как следствие, тоже.
Платформы умеют — это хорошо. Кстати, а что вы имеете в виду под словом «платформа»?
Я вижу за асинхронностью то же самое, что и за многопоточностью. Вот как-то так: «Можно использовать? Можно. Упрощает работу? Не факт. » Это должно быть приложение, написанное полностью в этом стиле, с учетом его особенностей и слабых мест.
Скажем, сервер-сайд игрушки для Контакта/Фейсбука можно написать так, и получить выигрыш в потреблении ресурсов процессора, потому как бэкэнд обычно пишется с нуля. Вместо трех машин в связке достаточно будет одной-двух. Ура.
Рядовой портальчик проще и надежнее наклепать на Джанге или вообще на чем-нибудь php-like.
Когда же изменится ситуация в целом — не ясно, как не ясно, изменится ли она вообще.
Я вижу за асинхронностью то же самое, что и за многопоточностью. Вот как-то так: «Можно использовать? Можно. Упрощает работу? Не факт. » Это должно быть приложение, написанное полностью в этом стиле, с учетом его особенностей и слабых мест.
Скажем, сервер-сайд игрушки для Контакта/Фейсбука можно написать так, и получить выигрыш в потреблении ресурсов процессора, потому как бэкэнд обычно пишется с нуля. Вместо трех машин в связке достаточно будет одной-двух. Ура.
Рядовой портальчик проще и надежнее наклепать на Джанге или вообще на чем-нибудь php-like.
Когда же изменится ситуация в целом — не ясно, как не ясно, изменится ли она вообще.
«Платформы умеют — это хорошо. Кстати, а что вы имеете в виду под словом «платформа»?»
Набор инструментов. Вот, скажем, .net — платформа. asp.net mvc — тоже платформа.
Просто то будущее, которое для вас «однажды», для меня уже здесь и сейчас.
Набор инструментов. Вот, скажем, .net — платформа. asp.net mvc — тоже платформа.
Просто то будущее, которое для вас «однажды», для меня уже здесь и сейчас.
Вы живете в платформах? :)
Ну, в этом-то смысле все платформы умеют в каком-то смысле асинхронность делать в том или ином виде. Те же сокеты неблокирующие уж сто лет в обед как работают, а с ними сам бог велел event loop наклепать.
А уже выше абстракции типа deferred или сопрограмм, или гринлетов, ну или чего там еще уже надумали за годы безделья :)
Вы лучше укажите, в какой именно сфере прикладной это вот прям ОЧЕНЬ-ОЧЕНЬ надо, чтоб я взял да и стал вдруг писать в этом стиле. Http-сервера мы уже обсуждали; не знаю как вам, а мне их писать часто не доводится :)
Ну, в этом-то смысле все платформы умеют в каком-то смысле асинхронность делать в том или ином виде. Те же сокеты неблокирующие уж сто лет в обед как работают, а с ними сам бог велел event loop наклепать.
А уже выше абстракции типа deferred или сопрограмм, или гринлетов, ну или чего там еще уже надумали за годы безделья :)
Вы лучше укажите, в какой именно сфере прикладной это вот прям ОЧЕНЬ-ОЧЕНЬ надо, чтоб я взял да и стал вдруг писать в этом стиле. Http-сервера мы уже обсуждали; не знаю как вам, а мне их писать часто не доводится :)
«Вы лучше укажите, в какой именно сфере прикладной это вот прям ОЧЕНЬ-ОЧЕНЬ надо, чтоб я взял да и стал вдруг писать в этом стиле.»
Все адекватные клиенты с удаленным сервером — чтобы не блокировать интерфейс на время обращения к серверу.
Более того, вообще любые клиенты с длительными операциями — в тех же целях.
Все адекватные клиенты с удаленным сервером — чтобы не блокировать интерфейс на время обращения к серверу.
Более того, вообще любые клиенты с длительными операциями — в тех же целях.
И-и-и-и-и-и? И какие же клиенты в настоящий момент одновременно будут однозначно превосходить традиционную многопоточную/многопроцессную модель — и быть достаточно простыми в использвонии?
Достаточно простыми для того, чтобы не ТОЛЬКО веб-сервера однозначно удобней было бы писать в таком ключе? Потому как последние — достаточно простые системы, в которых, по существу отличается только узловой момент — прием запросов. В них не возникает типичных проблем асинхронного программирования в силу независимости запросов.
Достаточно простыми для того, чтобы не ТОЛЬКО веб-сервера однозначно удобней было бы писать в таком ключе? Потому как последние — достаточно простые системы, в которых, по существу отличается только узловой момент — прием запросов. В них не возникает типичных проблем асинхронного программирования в силу независимости запросов.
Стоп, а где я говорил, что асинхронность как-то противоречит многопоточности?
Ровно наоборот, с моей точки зрения, асинхронность — это частный случай реализации многопоточности, где некоторые вещи убраны «под капот».
Ровно наоборот, с моей точки зрения, асинхронность — это частный случай реализации многопоточности, где некоторые вещи убраны «под капот».
Вы что-то путаете. Асинхронность — это асинхронность, многопоточность — это многопоточность.
Это перпендикулярные понятия. Иногда их используют вместе, иногда — порознь.
Под асинхронностью подразумеваются чаще всего некие неблокирующие вызовы. Скажем, в http-серверах это неблокирующее поток выполнения циклическое обращение к пулу событий на сокетах (select, poll или epoll в Линуксе).
Под многопоточностью — наличие в процессе нескольких параллельных потоков выполнения программы, имеющих доступ к общей памяти.
Над низкоуровневым асинхронным циклом событий иногда строят высокоуровневые примитивы: «легковесные» процессы, отложенные (deferred) обработчики и так далее.
Я утверждаю, что у всех этих примитивов есть некие проблемы, которые в достаточно большом количестве случае лишают подход однозначных преимуществ, а делает еще просто еще одним подходом.
Ну, мы отвлеклись. Я интересовался клиентами с длительными операциями, где асинхронный стиль дает преимущества.
Это перпендикулярные понятия. Иногда их используют вместе, иногда — порознь.
Под асинхронностью подразумеваются чаще всего некие неблокирующие вызовы. Скажем, в http-серверах это неблокирующее поток выполнения циклическое обращение к пулу событий на сокетах (select, poll или epoll в Линуксе).
Под многопоточностью — наличие в процессе нескольких параллельных потоков выполнения программы, имеющих доступ к общей памяти.
Над низкоуровневым асинхронным циклом событий иногда строят высокоуровневые примитивы: «легковесные» процессы, отложенные (deferred) обработчики и так далее.
Я утверждаю, что у всех этих примитивов есть некие проблемы, которые в достаточно большом количестве случае лишают подход однозначных преимуществ, а делает еще просто еще одним подходом.
Ну, мы отвлеклись. Я интересовался клиентами с длительными операциями, где асинхронный стиль дает преимущества.
«Вы что-то путаете. Асинхронность — это асинхронность, многопоточность — это многопоточность.»
Не путаю.
«Я утверждаю, что у всех этих примитивов есть некие проблемы, которые в достаточно большом количестве случае лишают подход однозначных преимуществ, а делает еще просто еще одним подходом.»
С этим я не спорю. Собственно, это и есть моя позиция.
«Я интересовался клиентами с длительными операциями, где асинхронный стиль дает преимущества. „
Банальный пример: вызов вебсервиса (не важно, откуда). В асинхронной модели я делаю вызов, указываю колбек — он будет вызван по завершению вызова, далее будет обработчик. В многопоточной модели мне надо будет положить синхронный вызов в отдельный поток и выполнить действия по его завершению. Лично для меня первое прозрачнее (еще и потому, что от меня скрывается то, на каких именно примитивах платформа реализует ожидание завершения вызова). Более того, именно первая модель позволяет сделать то, за что так хвалят js выше: всякие дополнительные упрощения в обработке коллбеков, например принудительную их сериализацию, которая убирает необходимость использования примитивов синхронизации внутри колбека.
Не путаю.
«Я утверждаю, что у всех этих примитивов есть некие проблемы, которые в достаточно большом количестве случае лишают подход однозначных преимуществ, а делает еще просто еще одним подходом.»
С этим я не спорю. Собственно, это и есть моя позиция.
«Я интересовался клиентами с длительными операциями, где асинхронный стиль дает преимущества. „
Банальный пример: вызов вебсервиса (не важно, откуда). В асинхронной модели я делаю вызов, указываю колбек — он будет вызван по завершению вызова, далее будет обработчик. В многопоточной модели мне надо будет положить синхронный вызов в отдельный поток и выполнить действия по его завершению. Лично для меня первое прозрачнее (еще и потому, что от меня скрывается то, на каких именно примитивах платформа реализует ожидание завершения вызова). Более того, именно первая модель позволяет сделать то, за что так хвалят js выше: всякие дополнительные упрощения в обработке коллбеков, например принудительную их сериализацию, которая убирает необходимость использования примитивов синхронизации внутри колбека.
«Не путаю» — эт что было, аргумент такой? :)
Ну давайте дальше пойдем по предложенному вами пути. Дернуть простой колбэк по событию. Дернуть другой колбэк по другому. Третий — по третьему. Им надо координировать действия или обменяться информацией. Как будете действовать?
Помнится, в js у меня иной раз довольно мутный код получался, нетривиальные решения приходилось принимать для сохранения читаемости кода. И замыкания дело только путали :)
В потоках мы вводим довольно неприятную систему локов и прочего дерьма, с этим связанного; и это тоже мне не нравится.
Ну давайте дальше пойдем по предложенному вами пути. Дернуть простой колбэк по событию. Дернуть другой колбэк по другому. Третий — по третьему. Им надо координировать действия или обменяться информацией. Как будете действовать?
Помнится, в js у меня иной раз довольно мутный код получался, нетривиальные решения приходилось принимать для сохранения читаемости кода. И замыкания дело только путали :)
В потоках мы вводим довольно неприятную систему локов и прочего дерьма, с этим связанного; и это тоже мне не нравится.
«Им надо координировать действия или обменяться информацией. Как будете действовать? „
Я же говорю — вводим принудительную синхронизацию коллбеков. После этого все проблемы координации нас волнуют мало.
Впрочем, мы можем пользоваться и все теми же локами и прочим цирком, придуманным для многопоточности.
Собственно, про что и речь: для меня нет разницы в асинхронности или многопоточности — в итоге и то, и другое приводит к одним и тем же проблемам, просто в одном случае создание потока и то, что в нем происходит, контролирую я, а в другом — фреймворк.
Я же говорю — вводим принудительную синхронизацию коллбеков. После этого все проблемы координации нас волнуют мало.
Впрочем, мы можем пользоваться и все теми же локами и прочим цирком, придуманным для многопоточности.
Собственно, про что и речь: для меня нет разницы в асинхронности или многопоточности — в итоге и то, и другое приводит к одним и тем же проблемам, просто в одном случае создание потока и то, что в нем происходит, контролирую я, а в другом — фреймворк.
>, в реальности там все равно будут проблемы с race conditions, одновременным доступом и так далее.
откройте для себя asynchronous message passing и shared-nothing architecture.
откройте для себя asynchronous message passing и shared-nothing architecture.
«Синхронное программирование»? WTF? en.wikipedia.org/wiki/Synchronous_programming
Автору низачот за перевод. Я вчера как раз подобное уже где-то вычитал: «По оценкам учёных, астероид был приблизительно 7,3 м в диаметре, и если бы он вошёл в нашу атмосферу, его энергия составила бы около 22 килотон.»
Люди, переводите то, в чем разбираетесь.
Автору низачот за перевод. Я вчера как раз подобное уже где-то вычитал: «По оценкам учёных, астероид был приблизительно 7,3 м в диаметре, и если бы он вошёл в нашу атмосферу, его энергия составила бы около 22 килотон.»
Люди, переводите то, в чем разбираетесь.
не придирайтесь, а скажите, как сделать лучше
Как это не придирайтесь? В правилах хабра не запрещено. Я высказываю свое мнение, и мне наплевать, 99% со мной не согласны или 98%.
Узкий кругозор приводит к тому, что всякие велосипедисты, называющие одни и те же вещи новыми именами, создают впечатление, что изобрели нечто новое. Как я уже указывал выше, терминология в переводе ваще лажовая. Синхронное программирование? Что это? Вот тут список языков синхронного программирования en.wikipedia.org/wiki/Synchronous_programming_language
А то, что в приложенном списке полезных ссылок «суперматериал», так то экскурс по давно обсосанным (и реализованным в других языках часто куда лучше, чем в питоне) енумераторам (т.е. банально один из видов ленивости вычислений) и потокам.
Но нет же, «корутины», «сопрограммы», «генераторы», «синхронное программирование» создают такой эффект, что просто у хабрашкололо отвисла челюсть, и топик типа клевый, типа с пивасиком пойдет. Намешали все до кучи в одну кашицу, не разбираясь в сабже толком. Что может быть лучшим показателем этого, чем использование не тех терминов? Корутины, твистер…
И да, о чем топик? Сейчас тут уже и в камментах даже налепили вместе и веб и многозадачность ОС. Каши уже столько, что каждому наестся хватит. Топик размытой терминологии о том, что… О том, что параллельные вычисления рулят? О том, что ленивые вычисления рулят? О функциональщине? О безопасном хаскеле? О славном питоне, в котором на самом деле те же лямбды кастрированы как нигде? Не топик, а огрызок неизвестного фрукта, пожевать который, конечно, всегда найдутся желающие…
Узкий кругозор приводит к тому, что всякие велосипедисты, называющие одни и те же вещи новыми именами, создают впечатление, что изобрели нечто новое. Как я уже указывал выше, терминология в переводе ваще лажовая. Синхронное программирование? Что это? Вот тут список языков синхронного программирования en.wikipedia.org/wiki/Synchronous_programming_language
А то, что в приложенном списке полезных ссылок «суперматериал», так то экскурс по давно обсосанным (и реализованным в других языках часто куда лучше, чем в питоне) енумераторам (т.е. банально один из видов ленивости вычислений) и потокам.
Но нет же, «корутины», «сопрограммы», «генераторы», «синхронное программирование» создают такой эффект, что просто у хабрашкололо отвисла челюсть, и топик типа клевый, типа с пивасиком пойдет. Намешали все до кучи в одну кашицу, не разбираясь в сабже толком. Что может быть лучшим показателем этого, чем использование не тех терминов? Корутины, твистер…
И да, о чем топик? Сейчас тут уже и в камментах даже налепили вместе и веб и многозадачность ОС. Каши уже столько, что каждому наестся хватит. Топик размытой терминологии о том, что… О том, что параллельные вычисления рулят? О том, что ленивые вычисления рулят? О функциональщине? О безопасном хаскеле? О славном питоне, в котором на самом деле те же лямбды кастрированы как нигде? Не топик, а огрызок неизвестного фрукта, пожевать который, конечно, всегда найдутся желающие…
Отличное замечание. Но с терминологией действительно швах. Asynchronous programming/synchronous programming — выражение регулярно встречающееся в оригинале мало связано с вашей ссылкой. Предложите свой вариант перевода, поправить тест не долго.
Приятно удивлен, что вместо ответного отбрасывания помидоров вы вежливо предложили сделать лучше. Но ссылки на источник я не вижу.
И как ниже заметил TheShock, проблема может быть и в самом исходнике. Но это, конечно, не оправдывает некачественность топика ) Если там и правда лажа, и нельзя с ней ничего сделать, то топик опубликован зря. Во всяком случае, это мое мнение.
И как ниже заметил TheShock, проблема может быть и в самом исходнике. Но это, конечно, не оправдывает некачественность топика ) Если там и правда лажа, и нельзя с ней ничего сделать, то топик опубликован зря. Во всяком случае, это мое мнение.
Если ссылка вас интересует ссылка на оригинал, то, как и во всех топиках преводах, она внизу www.eflorenzano.com/blog/post/how-do-we-kick-our-synchronous-addiction/
а мне в правилах хабра не запрещено делать замечания)
в вашем комменте есть доля истины.
но я не вижу проблем в том, чтобы назвать эту штуку синхронным программированием, все прекрасно поняли о чем речь в контексте топика.
из топика интересных идей не вынес, но это проблема не переводчика, а автора.
в вашем комменте есть доля истины.
но я не вижу проблем в том, чтобы назвать эту штуку синхронным программированием, все прекрасно поняли о чем речь в контексте топика.
из топика интересных идей не вынес, но это проблема не переводчика, а автора.
en.wikipedia.org/wiki/Enumerator напридумывали, действительно
The term «coroutine» was originated by Melvin Conway in his seminal 1963 paper.[1]
На корутинах написана «Матрица». ИМХО.
Вот смысл в вебе писать асинхронщину, если там и так несколько потоков, каждый из которых занят своим запросом? Оно уже распараллелено.
А если нужно отдать страничку сейчас и выполнить что-то тяжеловесное в фоне, то в том же ASP (про руби не знаю, не писал) есть примекрно вот такая штука:
public ActionResult BeginAsyncAction()
{
new System.Threading.Thread(delegate
{
//Тут выполняем всякие долгие операции
}).Start();
return View();
}
А если нужно отдать страничку сейчас и выполнить что-то тяжеловесное в фоне, то в том же ASP (про руби не знаю, не писал) есть примекрно вот такая штука:
public ActionResult BeginAsyncAction()
{
new System.Threading.Thread(delegate
{
//Тут выполняем всякие долгие операции
}).Start();
return View();
}
Наглядный пример из веба: чтобы загрузить пачку объектов из стораджа, нужно сходить в 10 шардов, и потом еще в 10 других. Каждый запрос в шард стоит в среднем N миллисекунд. В синхронном варианте это выльется в N*20, в асинхронном — в то же N.
Неверно. Под нагрузкой это будет те же самые N*20, послкольку другие ядра процессора тоже заняты. Более того, это будет медленнее из-за оверхеда на создание и обслуживание доп. потоков и переключение между ними.
Конечно, если у вас данные тянутся через сеть, то надо распараллеливать. Только вот не должны 20 объектов тянуться через сеть да ещё и из разных мест. Если это происходит, то проблема не в синхронности, а в архитектуре. В любом случае, во фреймворке есть классы для асинхронных запросов, можете их использовать, например, причём вполне даже прозрачно.
Конечно, если у вас данные тянутся через сеть, то надо распараллеливать. Только вот не должны 20 объектов тянуться через сеть да ещё и из разных мест. Если это происходит, то проблема не в синхронности, а в архитектуре. В любом случае, во фреймворке есть классы для асинхронных запросов, можете их использовать, например, причём вполне даже прозрачно.
Это пример не из веба, а из системы с распределенным хранилищем данных. И с точки зрения _веба_, т.е., контроллера, это должен быть один синхронный запрос: ДайДанные(). А уж как его подсистема данных разнесет внутри себя — ее личное дело.
А что, веб начинается только от контроллера и выше? Ну хорошо, а сам веб-сервер к вебу относится? См пример с нжинксом чуть ниже.
Веб начинается от Presentation Layer. Ваша же задача — Service Layer.
«Ну хорошо, а сам веб-сервер к вебу относится?»
В контексте разговора — нет. Собственно, именно потому, что вебсервер — это та хрень, которая позволяет нам обрабатывать каждый запрос синхронно, и при этом сохранить независимость обработки одного запроса от другого. Уровень абстракции.
«Ну хорошо, а сам веб-сервер к вебу относится?»
В контексте разговора — нет. Собственно, именно потому, что вебсервер — это та хрень, которая позволяет нам обрабатывать каждый запрос синхронно, и при этом сохранить независимость обработки одного запроса от другого. Уровень абстракции.
ну а если у вас долгоживущие коннекты? Комет какой-нибудь. Сервер получает изредка что-то из AMPQ и пишет это в клиенту в сокет. И таких вяловисящих коннектов 10 тысяч.
Только не говорите, что будете делать 10 тысяч простаивающих тредов под каждый коннект. См. nginx, который все коннекты держит в одном потоке, а не форкается каждый раз аки апач.
См. Windows Completion Ports, которые отправляют сообщения в свободный поток из пула.
я??? Эээ. Это вы как раз говорите что собираетесь долгие процессы в системных тредах пускать. И что у вас каждым запросом занят один тред.
Мы то как раз открываем асинхронные соединения и создаем 10 тыс. зеленых тредов в одном настоящем потоке. Ровно так-же как это делает nginx.
Мы то как раз открываем асинхронные соединения и создаем 10 тыс. зеленых тредов в одном настоящем потоке. Ровно так-же как это делает nginx.
Кстати, во втором MVC рекомендуется использовать Async Actions для этого, чтобы не захламлять пул потоков asp.net.
Всему свое место.
Если мы делаем интерфейс, то появляется много событий и нужно делать асинхронно. Но запросы к серверу должны быть короткими и ясными как выстрел и тут совсем не зачем делать асинхронность, которая, надо признать, всегда усложняет код и поддержку.
Если мы делаем интерфейс, то появляется много событий и нужно делать асинхронно. Но запросы к серверу должны быть короткими и ясными как выстрел и тут совсем не зачем делать асинхронность, которая, надо признать, всегда усложняет код и поддержку.
НЛО прилетело и опубликовало эту надпись здесь
а как же параллельное программирование? оно тут не поможет?
НЛО прилетело и опубликовало эту надпись здесь
Разве Ruby 1.9 не имеет Fibers, о который говорит автор, называя их сопрограммамами?
Я что-то не понимаю, о чём статья. Об очередях сообщений? Ну дык они уже давно используются, например, во многих GUI-фреймворках, и никто не жалуется. Ну а зачем использовать их где попало? Ну и тем более, что в ОС как раз есть на низком уровне эта самая «очередь сообщений». Называется планировщик задач. Только там сообщением потенциально может оказаться одна машинная инструкция. И мир уже давно пользуется фичами, предоставляемыми такой вот очередью сообщений.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как избавиться от пристрастия к синхронности