Здравствуйте, Ikemefula, Вы писали:
N>>На этом месте я перестал понимать, что же ты доказываешь. N>>Твой пример, с которым ты влез в эту подветку, относился к ситуации примерно следующего вида: N>>1. Действие A заказывает две внешние операции, для первой коллбэк B, для второй C. N>>2. C (когда оно вызовется) сложит ответ в некоторый компонент глобального состояния. N>>3. B вызывается со своим ответом и ожидает, что уже есть ответ от C. Но его нет, поэтому B получает чушь. N>>4. C вызвался после B, но чушь уже состоялась.
I>Нет, не про это. Есть логическая задача, которая работает с глобальным ресурсом. Она асинхронная и довольно длинная. Нужно запустить параллельно еще несколько таких же задач при сохранении всех инвариантов.
Ну это уже точно какой-то transaction manager получается.
N>>Если это так, это действительно проблема, с которой борются своими методами. Например, для JS это может быть отработано так. И в B, и в C как в замыкания передаётся объект (не обязательно глобальный!) R, по ссылке. B кладёт в него свой результат, C — свой, но оба проверяют: если уже есть оба ответа, они немедленно вызывают финальную обработку суммарного результата. I>Как ты передашь базу данных или файл в замыкании ?
Файл — хэндлом открытого файла. Базу — хэндлом клиента (чем бы он ни был). Не?
Мы всё ещё в контексте node.js как основного средства?
Или ты про результат операции типа read или select? так это просто данные.
N>>Верно. Остался один вопрос — нафига так делать? И какие реальные ситуации заставили тебя рисовать такой пример?
I>Есть скажем кусок линейного кода в JS, который отлажен, оттестирован. Теперь, внезапно, эта задача может запускаться в нескольких экземплярах работающих параллельно. Наиболее дешовый способ это оставить логику, как есть, только выровнять доступ к глобальному ресурсу. I>В простых случаях этого более чем достаточно. В более сложных придется пилить чтото навроде агентов, и здесь, что характерно, снова все вокруг глобального ресурса.
Понятно. Я вынужден сказать тут, что в вашем споре не согласен с обоими — твоё начальное возражение было ближе к неуместному, а оппонент взвился и обрушился на отражение в кривом зеркале, даже не заметив, что отразился скорее он сам
Flame.comp в полный рост, даже без троллей.
Здравствуйте, netch80, Вы писали:
I>>Нет, не про это. Есть логическая задача, которая работает с глобальным ресурсом. Она асинхронная и довольно длинная. Нужно запустить параллельно еще несколько таких же задач при сохранении всех инвариантов.
N>Ну это уже точно какой-то transaction manager получается.
Для серьезных случаев он и будет нужен, особенно есть есть кейсы отмены, отмены отмены, паузы и разные возобновления. В простых эе случаях нужна обычная очередь операций. Она, фактически, может являться своего рода асинхронным мутексом или семафором.
Собственно я сейчас уперся именно в такие кейсы и всё дело идет замене на чтото более серьезное.
I>>Как ты передашь базу данных или файл в замыкании ?
N>Файл — хэндлом открытого файла. Базу — хэндлом клиента (чем бы он ни был). Не? N>Мы всё ещё в контексте node.js как основного средства? N>Или ты про результат операции типа read или select? так это просто данные.
Про последовательность доступа. Здесь не важно, Node.js или чтото еще. Можно решить разными способами, я не спорю. Я скорее говорю о наличии фундаментальной проблемы. Потому как многие почитали у того же микрософта "в асинхронном коде гонок нет" и на этом основании придумывают уникальный велосипед, что бы решить проблему. Это слишком дорого, исправлять ошибки в таком вот асинхронном коде.
Здравствуйте, Sharov, Вы писали:
S>И да, раз уж Эрланг так крут, чего же гугл стал изобретать свой велосипед Go, а не форкнул Эрланг. S>Эрланг это язык, конкретно заточенный под телеком, со своими минусами и плюсами. Зачем его всюду пихать? S>Это исключительно нишевый язык.
Эрланг, если не брать в рассчет сам язык, идеально подходит под очень многие сценарии обычных веб-приложений.
Если нет числодробилок, параллельных вычислений, не требуется тяжелый функционал ОС, то мало кто справляется с работой лучше Эрланга.
У меня вот было желание перейти в Эрланг, но вместо этого попробовал в node.js а оттуда затянуло ажно в браузер
Реально у Эрланга один большой недостаток — порог входа довольно высокий. Туда идут обычно люди, которые уже прошли 2-3 технологических стека.
БОльшую часть вещей в Эрланге нельзя пощупать непосредственно, то есть руками. И это создает проблемы в освоении.
Но вообще спрос на вещи навроде Эрланга будет расти. Веб-приложения потиху вырастают из простого CRUD и превращаются в процессинговые центры.
Эту нишу мог бы занять и Node.js, но реально ручная диспетчеризация асинхронного кода это адский АДъ.
Здравствуйте, Ikemefula, Вы писали:
I>Реально у Эрланга один большой недостаток — порог входа довольно высокий. Туда идут обычно люди, которые уже прошли 2-3 технологических стека.
не соглашусь. там нет ничего сложного. просто фп не сильно популярно.
а через пару недель обучения я уже успешно патчил ежа под свои нужды. так что сложность переоценена.
I>БОльшую часть вещей в Эрланге нельзя пощупать непосредственно, то есть руками. И это создает проблемы в освоении.
что именно нельзя? там вроде доступно всё.
I>Но вообще спрос на вещи навроде Эрланга будет расти. Веб-приложения потиху вырастают из простого CRUD и превращаются в процессинговые центры. I>Эту нишу мог бы занять и Node.js, но реально ручная диспетчеризация асинхронного кода это адский АДъ.
да, и первый нативный язык с аналогичными фичами имхо отберёт эту нишу у эрланга. последний останется только в телекоме.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Там основная работа делается только один раз, в виде библиотеки.
Ага, знаем мы про один раз. Так всю жизнь и придется писать эти "один раз".
НС>>Но для веб- или REST приложений, где оно больше всего востребовано, оно и так уже такое. Т.е. экземпляры чисто прикладных классов между запросами как правило не живут. Так что правишь страничку и следующий же рефреш показывает новый вариант, без сброса приложения и сессии. EP>Для такого примитивного сценария подойдёт даже простая замена исполняемого файла / "cgi" скрипта / и т.п.
Нет, не подойдет. Веб-приложения давно уже сильно больше чем просто cgi скрипт. Сессии, к примеру, никто на каждый запрос не десериализует.
EP> Такое и в C++ есть "искаропки"
Такого нет. Перегружается то не все приложение, а только конкретный обработчик конкретного url.
EP>Выше же речь шла про онлайн игры, а в них общий игровой мир живёт "сам по себе".
Это отдельный вопрос как там живет игровой мир. Держать в памяти большие игровые миры на каждого клиента — отличный способ отстрелить себе ногу.
Здравствуйте, Ночной Смотрящий, Вы писали:
EP>>Там основная работа делается только один раз, в виде библиотеки. НС>Ага, знаем мы про один раз. Так всю жизнь и придется писать эти "один раз".
Готовые плагинные библиотеки существуют, причём давно.
EP>> Такое и в C++ есть "искаропки" НС>Такого нет. Перегружается то не все приложение, а только конкретный обработчик конкретного url.
И в чём принципиальная разница в обсуждаемом контексте?
EP>>Выше же речь шла про онлайн игры, а в них общий игровой мир живёт "сам по себе". НС>Это отдельный вопрос как там живет игровой мир. Держать в памяти большие игровые миры на каждого клиента — отличный способ отстрелить себе ногу.
А зачем его держать на каждого клиента? Он один общий на всех, и в нём реализуется некоторая логика, и вот эту логику можно патчить "наживую".
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>>>Там основная работа делается только один раз, в виде библиотеки. НС>>Ага, знаем мы про один раз. Так всю жизнь и придется писать эти "один раз". EP>Готовые плагинные библиотеки существуют, причём давно.
А вот готовых серверов с автоматической перезагрузкой прикладного кода почему то нет. А вот для джавы и дотнета — есть.
НС>>Такого нет. Перегружается то не все приложение, а только конкретный обработчик конкретного url. EP>И в чём принципиальная разница в обсуждаемом контексте?
Принципиальная? Не, она не принципиальная, она конкретная.
НС>>Это отдельный вопрос как там живет игровой мир. Держать в памяти большие игровые миры на каждого клиента — отличный способ отстрелить себе ногу. EP>А зачем его держать на каждого клиента? Он один общий на всех
Для этого потребуется уникальный рантайм как минимум. Ну и общий на всех прямо в памяти — тоже хороший способ отстрела ноги.
Здравствуйте, Ikemefula, Вы писали:
I>Реально у Эрланга один большой недостаток — порог входа довольно высокий. Туда идут обычно люди, которые уже прошли 2-3 технологических стека.
Наша команда самого большого эрлангового проекта наполовину состояла из людей, вообще до того не имевших опыта программирования под заказ или своих проектов более страницы. Входить им было даже легче, чем некоторым до того опробовавшим разные языки и стеки. Отсутствие привычки к императивщине тут, оказалось, помогает.
I>Но вообще спрос на вещи навроде Эрланга будет расти. Веб-приложения потиху вырастают из простого CRUD и превращаются в процессинговые центры. I>Эту нишу мог бы занять и Node.js, но реально ручная диспетчеризация асинхронного кода это адский АДъ.
JIMHO даже не столько ручная диспетчеризация, сколько отсутствие средств диагностики типа "а сколько у нас отложенных заданий помечено тегом Forum", возможности произвести массовый отстрел или модификацию по некоторому критерию, и т.д.
Здравствуйте, Ночной Смотрящий, Вы писали:
N>>Это тебе с HTTP такая радость? НС>Не только мне.
Неважно. Важно, что это
N>> Ну ну. У меня то SIP, то FIX, то RPC по Redis+ZeroMQ... N>>никакие "системные сборки" такого не поддержат НС>Да какая разница? Не пихаешь же ты логику протокола и прикладной код в одну сборку/класс.
1. Идут правки и в логике протокола, причём сильно чаще, чем хотелось бы. Особенно в случае SIP — эта 4-уровневая скотина с некоторыми особенностями, которые с ящиком водки не осилить.
2. Ты завязался на то, что системная сборка всегда права, иначе смотри начало пункта (или рис.1).
технологических стека.
N>Наша команда самого большого эрлангового проекта наполовину состояла из людей, вообще до того не имевших опыта программирования под заказ или своих проектов более страницы. Входить им было даже легче, чем некоторым до того опробовавшим разные языки и стеки. Отсутствие привычки к императивщине тут, оказалось, помогает.
Это как, вообще программировать не умели ? I>>Эту нишу мог бы занять и Node.js, но реально ручная диспетчеризация асинхронного кода это адский АДъ.
N>JIMHO даже не столько ручная диспетчеризация, сколько отсутствие средств диагностики типа "а сколько у нас отложенных заданий помечено тегом Forum", возможности произвести массовый отстрел или модификацию по некоторому критерию, и т.д.
Если это то что я понимаю, то такие вещи уже появились — куча всевозможных шедулеров, менджеров и тд. Я правда не могу сказать, насколько это эффективно работает, не работал.
Здравствуйте, Ikemefula, Вы писали:
I>Кстати, вопрос такой — ты в курсе, что Windows до определенной версии поддерживала только кооперетивную многозадачность ? I>Ты в курсе, что уже тогда в ней были и семафоры, и муткесы.
Семафоры и мьютексы более использовались для сигналинга м/у процессами, внутри одного процесса обычно пользовали CRITICAL_SECTION.
Ну и еще в Windows 16 работали перывания прямо в юзверском коде ))
Поэтому, если твоя прога сидела на прерываниях, то эти прерывания тоже как-то обыгрывались: либо ресурсы защищались теми же критическими секциями, либо для какого-то участка кода запрещались прерывания.
I>Как так, ведь в кооперативной многозадачности "гонок нет"
В Windows 16 (если ты о ней) кооперативный шедулер срабатывал на КАЖДЫЙ вызов системного АПИ, наверно в этом дело?
Т.е., ты пытаешься сравнить ситуацию, когда ты вручную расставляешь точки переключений задач с ситуацией, когда у тебя эти точки переключения задач расставлены даже в тех местах, где ты бы НЕ ХОТЕЛ, чтобы переключение произошло.
I>Все очень просто — ты хочешь съехать с кооперативной многозадачности.
Ы?
I>У тебя вытесняющая многозадачность, а я говорю про кооперативную. Представь себе, гонки это свойство любой многозадачности, а не только вытесняющей.
Я думаю, что ты пытаешься впасть в ту не раз наблюдаемую у некоторых коллег ересь, что, используя любой тьюринг-полный язык, на ём можно проэмулировать любые эффекты, достижимые в современных тьюринг-полных выч. системах.
Я же пытаюсь рассуждать о том, что у нас есть в "базе", потому что именно ср-ва из "базы" являются ср-вами шаговой доступности в языке, а всё остальное — только через библиотеки и трюки.
В базе жабаскрипта есть вполне детерминированная однопоточная модель вычислений — ты можешь пользоваться знаниями об этом.
Например, в случае вытесняющей многозадачности, для сериализации доступа к разделяемому ресурсу ты должен писать как-то так:
Но в жабаскрипте для обеспечения детерминированности достаточно, чтобы м/у точками (1) и (2) не произошло переключения задач. Т.е. не вставляй м/у точками (1) и (2) никаких await/yield и всех делов.
Если же ты м/у этими точками вставляешь инструкции переключения потоков, то твоя недетерминированность создана искусственно, т.е. является эмуляцией недетерминированности с помощью детерминированного инструмента.
I>У тебя плохой пример. Раздели чтение переменной и запись на две операции. Внезапно, обнаруживаем инвариант — поток затирает ровно то значение, которое перед этим прочёл.
Да, но где здесь недетерминированность?
Вот у меня код на жабаскрипте:
var x = 1;
x = x * 10;
x = x - 5;
В условиях детерминированности ты можешь в своей программе полагаться на значение x. Это фундаментальное св-во, лежащее в основе вcего программирования, что ты можешь полагаться на логику своей собственной программы.
Теперь другой пример:
var x = 1;
async function f1() {
var x1 = x * 10;
await someAsyncOp(); // (1)
x = x1 - 5;
}
Пример тоже полностью детерминированный. Ты можешь полагаться на значение локальной переменной x1, но уже не можешь полагаться на значение x после ручного переключения потоков на await.
Собсно, знания о том, какие значения являются детерминпированными, а какие нет, тоже составляют фундамент многопоточного программирования. ))
В последнем примере x1 — это личный ресурс, а x — разделяемый.
Но это не "само так получилось", не? Это так код был специально написан, чтобы x стал разделяемым ресурсом, да еще чтобы обязательно что-то с ним произошло м/у операциями чтения или записи. В последнем примере достаточно поменять строку (1) со строчкой сверху или снизу, чтобы ты опять вернулся к детерминированным рассуждениям относительно x.
I>Если компилятор не гарантирует атомарность инкремента
Компилятор ничего не может гарантировать. Он просто использует низлежащую модель вычислений.
I>многозадачный код ломает этот инвариант. I>Отсюда ясно, что не состояние неопределено, а порядок выполнения недетерминирован, ибо может быть реально так:
I>thread1 read i I>thread2 read i I>thread1 write i + 1 I>thread2 write i + 1
Слава те хосподя, об этом и пример ))
I>И именно эта последовательность ломает состояние. То есть, гонки налицо. Видишь их?
Для случая С++? Конечно, это же был мой пример.
I>Теперь твой пример на JS, вместо потока — задача. Что читаем i и записываем отдельно. I>Запускаем один таск — никаких нарушений инварианта нет, всё шоколадно. I>Запускаем второй таск, опаньки — инвариант ломается.
Ну он же не сам поломался, это ты специально, ручками, сделал так, чтобы переменные i и actual изменялись/проверялись в РАЗНЫХ циклах запуска жабаскрипта. А ты сделай так, чтобы эти переменные изменялись в рамках одного цикла запуска скрипта и всё будет ОК.
I>Здесь, внимание, порядок выполнения зависит исключительно от того, в какой момент стартовал новый таск.
Да похер, сорри.
Ты НЕ можешь полагаться на значение переменных, оставшихся с прошлого запуска, потому что тебе недоступна история этих прошлых хапусков, не предоставляет жабаскрипт такой инфы, ты можешь полагаться на значения переменных, прочитанных в рамках текущего запуска.
Ты вообще смотрел мой пример? Не обратил внимание на такой момент:
// подпишись сюда в браузере на событие с клавиатурыfunction onKeyboard(nextChar)
{
keyboardQueue.push(nextChar);
if(keyboardAwaiter != null) {
var awaiter = keyboardAwaiter;
keyboardAwaiter = null;
awaiter(keyboardQueue.take());
}
}
Если бы мне было доступно управление порядком очереди событий к хосту жабаскрипта, мне не нужна была бы очередь событий с клавиатуры, мне достаточно было бы одной переменной, хранящей последнюю нажатую кнопку. Но т.к. я НЕ знаю, какой событие за каким будет выполнено в реальности, я делаю буфер-очередь.
Но зато к самой очереди я обращаюсь БЕЗ каких-либо блокировок, т.к. низлежащая модель вычислений такова, что весь мой код, считай, обложен парой DisableInterruptions/EnableInterruptions.
И ты, именно ты, как программист, должен ЗНАТЬ низлежащую вычислительную модель. Ты должен знать, что твой жабасрипт НЕ прервется ни в какой точке исходника до тех пор, пока ты сам же, явно его не прервёшь. И если ты не обладаешь этими знаниями, то ты еще не готов программировать на этом зыке. Вот и всё кино.
I>ОС следит только за протоколом файловой системы. Что ты запишешь в файл, ты не знаешь, если писателей больше одного и твоей синхронизации нет. I>И если два потока пишут в один файл, не важно, логических или физических, результат может быть недерминирован.
Ну так открывай файл с исключительным доступом, елки. И не шарь владение хендлом на файл.
Я пока проблему никак не могу уловить.
Не мог бы ты озвучить ТЗ целиком?
I>Это, в частности, проявляется в том, что содержимое файла при одном запуске будет "111222" а во втором случае "121212" а в третьем "122211"
Здравствуйте, Ikemefula, Вы писали:
I>В простых эе случаях нужна обычная очередь операций. Она, фактически, может являться своего рода асинхронным мутексом или семафором.
Асинхронные мьютексы ставят раком всю аснхронность.
Собсно, как синхронные мьютексы ставят раком вытесняющую многозадачность.
И точно так же на асинхронных мьютексах возможен тот самый дедлок.
Асинхронный мьютекс делает ровно одно — task reordering, то бишь пуляет продолжение текущего кода в конец очереди вычислений. Вот так два асинхронных мьютекса и будут бесконечно пулять две задачи при асинхронном дедлоке.
И это при том, что асинхронщина толкается как инструмент №1 для избавления от дедлоков, ы-ы-ы.
I>Собственно я сейчас уперся именно в такие кейсы и всё дело идет замене на чтото более серьезное.
Еще пару лет назад тебя приглашали озвучить ТЗ. Ты так и не сподобился.
Потому что известные решения есть и их больше одного. Но непонятно, что тебе надо. Твой node.js и асинхронщина в нем — не первая и не последняя в истории человечества. Всё уже изобретено до нас.
А изобретателей асинхронных мьютексов вменяемые разработчики давно послали туда, где им место.
Это же надо было, вместо того, чтобы создать нужные зависимости, додуматься тупо отпуливать таски в конец очереди... бррр... ))
Здравствуйте, netch80, Вы писали:
N>Без разрыва соединений,
Это надуманно. Все клиентские игрушки не полагаются на постоянное TCP/UDP соединение, т.е. переустанавливают соединение при его потере.
N>без замораживания всех одновременно до момента перехода, с минимальной задержкой на сам переход (необходимые конверсии структур плюс небольшие накладные расходы на процесс перехода).
Это все-равно намного быстрее, чем все потоки интерпретатора перепрочтут бесконечные исходники скриптов.
N>То есть все замораживаются, состояния сериализуются, выгружается код, загружается новый, состояния десериализуются и всё запускается опять? Или можно сократить цепочку?
Конечно, можно сократить.
Игрушки используют некий бэкенд (базу, скажем), куда с некоторой периодичностью (обычно раз в несколько сек) постоянно скидывают своё состояние. Вот как раз после очередного скидывания состояния можно накатить update и переподнять сервак с новым кодом. Ведь не надо же обновлять всю базу — достаточно будет обновить только последний апдейт.
Ну, или же, если процесс обновления базы долгий, то можно взять транзакционно снапшот и в рамках же этой транзакции указать, что последующие изменения данных базы надо складывать еще в такую-то очередь. Затем конвертируется последний снапшот, потом конвертируется очередь обновлений, а как только эта очередь будет пуста на момент следующего сохранения изменений, то вот тут-то и "переехать" на новую базу.
Здравствуйте, Ночной Смотрящий, Вы писали:
EP>>Там основная работа делается только один раз, в виде библиотеки. НС>Ага, знаем мы про один раз. Так всю жизнь и придется писать эти "один раз".
Ну, COM написан уже лет 30 назад и там именно такая инфраструктура.
Здравствуйте, so5team, Вы писали:
S>Как я понимаю, эта либа была написана одним разработчиком, в свободное время и под себя.
Да я ж не спорю.
Просто в обсуждении ссылались на эту либу не раз, как и на другие, скажем так, намного более серьезные либы.
Кароч, это просто некий эффект от ожидания совсем другого.
Здравствуйте, netch80, Вы писали:
N>1. Идут правки и в логике протокола
Это, скажем так, не самая часто встречающаяся ситуация.
N>2. Ты завязался на то, что системная сборка всегда права, иначе смотри начало пункта (или рис.1).
Нет, не завязался. Просто изменения системных сборок потребуют рестарта приложения. Все равно это не С++ и ни о каких кофе во время перекомпиляции речи не идет.
