обращайтесь

но вообще https://habrahabr.ru/post/150788/ всё объясняет

в любом случае спасибо за информацию

но вообще https://habrahabr.ru/post/150788/ всё объясняет

Не всё.

кому-то нравится ставить точку с запятой (обычно тем, кто пришёл с других языков, где она есть), кому-то не нравится

Я с Java пришёл. Этот принцип - просто синдром утенка

А в php точно есть многопоточность? похоже на гон

pthreads

Я с Java пришёл. Этот принцип - просто синдром утенка

я с питона пришёл и ставлю точку с запятой в большенстве случаев. так что такое себе утверждение

Shit happens

воу

воу

М?)

я с питона пришёл и ставлю точку с запятой в большенстве случаев. так что такое себе утверждение

ну вот воу

Асинхронность, Promise, async/await - это почти тоже самое, что и потоки, только переключение происходит в предсказуемых местах, а не посреди выполнения абсолютно любой машинной инструкции. Следовательно проблемы синхронизации, дедлоков и гонок полностью исчезают. Такая модель удобна для подавляющего большенства практических задач за исключением выполнения длительных и тяжёлых вычислений, нагружающих CPU. Если вы проводите такие вычисления на NodeJS, то вы скорее всего куда-то не туда повернули в своей жизни. Если вы уверены в своей правоте и хотите дробить числа и перемножать матрицы именно на NodeJS, то лучше всё-таки вынести всё это дело в отдельный процесс.

чёрт

а я истфака

ставлю то что по код стайлу

Асинхронность, Promise, async/await - это почти тоже самое, что и потоки, только переключение происходит в предсказуемых местах, а не посреди выполнения абсолютно любой машинной инструкции. Следовательно проблемы синхронизации, дедлоков и гонок полностью исчезают. Такая модель удобна для подавляющего большенства практических задач за исключением выполнения длительных и тяжёлых вычислений, нагружающих CPU. Если вы проводите такие вычисления на NodeJS, то вы скорее всего куда-то не туда повернули в своей жизни. Если вы уверены в своей правоте и хотите дробить числа и перемножать матрицы именно на NodeJS, то лучше всё-таки вынести всё это дело в отдельный процесс.

немного из контекста вырвано, но надеюсь смысл понятен

Асинхронность, Promise, async/await - это почти тоже самое, что и потоки, только переключение происходит в предсказуемых местах, а не посреди выполнения абсолютно любой машинной инструкции. Следовательно проблемы синхронизации, дедлоков и гонок полностью исчезают. Такая модель удобна для подавляющего большенства практических задач за исключением выполнения длительных и тяжёлых вычислений, нагружающих CPU. Если вы проводите такие вычисления на NodeJS, то вы скорее всего куда-то не туда повернули в своей жизни. Если вы уверены в своей правоте и хотите дробить числа и перемножать матрицы именно на NodeJS, то лучше всё-таки вынести всё это дело в отдельный процесс.

про гонки неправда

Мораль сей басни такова: с точки зрения программиста асинхронность (с async/await, а не с callback hell) почти всегда лучше и удобнее, чем потоки.

ставлю то что по код стайлу

Конформист)) ?

про гонки неправда

что же там неправильного?

"полностью исчезают"

О даа

На промисах можно такую гонку наворотить, круче тур де франс

На промисах можно такую гонку наворотить, круче тур де франс

не надо чистые промисы, когда есть async/await

Это не принципиально

кстати, Питон со своим GIL тоже фактически однопоточным получается

причём там совсем всё плохо, так как собираются вместе часть недостатков потоков и асинхронности

Это не принципиально

в любом случае, на потоках гонку (и не только её) наворотить гораздо легче, чем в async/await

там есть асинхронность чуть что

там есть асинхронность чуть что

есть, да, можно всё асинхронно писать

тогда потоки вообще бесполезными становятся

и как вообще можно сделать гонку в NodeJS?

Просто посчитать, что одна асинхронная операция выполняется всегда быстрее другой (скорее всего, абсолютно неявно)

Готово, можете звать спортсменов

Особенно это весело, когда они реально должны выполняться параллельно, просто при этом случай, когда B дольше A автору не попадался

ну как бы есть Promise.all

для ожидания всех нужных запущенных асинхронных операций

без всяких пердположений о скорости выполнения каждой из них

Очень хорошо рассуждать в теории

И на двух отдельно взятых объектах

К сожалению, в местах, где возникают такие ситуации, всё обстоит обычно слегка иначе

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

может я чего-то недопонимаю

Просто для удобства программистов ничего более предсказуемого, чем ручного переключения контекста (async/await) парраллельных единиц (корутин или потоков) не придумали. И если и в этом случае делать такие ошибки, то тут уже ничего не поможет.

Если я кину ссылку на либу целиком, то это будет некорректным примером

Но к сожалению, когда всё понятно, то и проблем нет, но так бывает далеко не всегда

Ну хотя бы некий небольшой пример кода.

Первые 2 тысячи строк сойдет?

Ошибка в том, что почему то берется по умолчанию, что в коде всё предельно ясно и логически по фен шую

что-то сомневаюсь, но можно попробовать

ну есть реактивные библиотеки которые решают множество таких проблем

Особенно это весело, когда они реально должны выполняться параллельно, просто при этом случай, когда B дольше A автору не попадался

типа RxJS

да даже async/await и Promise.all уже решают

у них встроенные методы почти под все виды так сказать синхронизации асинхронных событий

Окей, вот вам максимально краткий пример

Если мы выполняем вот эту функцию, то авторизация проходит по плану https://github.com/zerobias/telegram-mtproto/blob/develop/src/bin.js#L332 Если мы заменяем код на абсолютно аналогичный (инфа 100%) из другой библиотеки, то с вероятностью в 30% падаем в 404, потому что вычисления идут дольше чем запланировано и определенный код не срабатывает https://github.com/zerobias/telegram-mtproto/blob/cbdc272e8cd17ef96312560f0504d6b47554f4f2/source/bin.js#L534

Когда найдете причину, оформите пул реквест и разбудите меня из летаргического сна

Надеюсь, я достаточно красочно проиллюстрировал суть проблем при состояниях гонки и почему причина не в том что "можно заюзать Promise.all"

Это какой то плохой пример

Я к тому же, ага

Тут все синхронно

Потмоу что в хороших примерах нет проблемы

Тут все синхронно

Здорово, правда?

Всем привет, товарищи , подскажите глупому , можно ли найти вещественное решение системы из n линейных уравнений при m(m>n) неизвестных ? #offtop

Просто видимо за счет этой операции ты меняешь тайминг асинхронной операции, которая ее вызывает

ERROR: S client not available

Там много "почему", на самом деле, в этом и причина

Просто меня пытаются убедить в том, что состояния гонки - это от того, что можно заюзать %method_name%, когда на самом деле проблема в том, что иногда очень объёмные части самого разного кода действуют параллельно

Этот метод вызывается, кажется, несколько тысяч раз за пару секунд

Ну эта проблема можно быть глобально только есть бесконтрольная мутация глобального стейта

я думаю очевидно, что в синхронном коде не может быть проблем с асинхронностью, если он не использует изменяемые объекты

Если этого нет, то это проблема вполне локальная

И просто заключается в том что ты не дожидаешься какой то операции

Хорошее определение для фразы "состояние гонки", но проблему решить оно не позволяет

если проблема есть, то не в этом коде, а в том, который его вызывает

Вполне позволяет, в тех случаях о которых я говорю

Авторизация использует точный тайминг на данный момент, от тяжёлых вычислений часы слегка рассинхронизируются

Если ты где то запускаешь операцию, которая асинхронно мутирует глобальный стейт, то просто не нужно так делать

Такие моменты действительно сложно определить

Хорошо, когда буду мутировать, сообщу

Судя по твоему описанию проблемы, ты уже это делаешь

Авторизация использует точный тайминг на данный момент, от тяжёлых вычислений часы слегка рассинхронизируются

а вот это уже интересно, правда я бы не назвал это гонкой

Да, это из другой оперы

Если ты где то запускаешь операцию, которая асинхронно мутирует глобальный стейт, то просто не нужно так делать

Можно на самом деле, только очень аккуратно и постоянно держать в голове то, что этот объект может быть изменён где-то в другом месте. И крутость однопоточной асинхронности заключается в том, что даже нетривиальные изменения будут внесены атомарно (если конечно не написать внутри кода внесения изменений await something()).

Можно на самом деле, только очень аккуратно и постоянно держать в голове то, что этот объект может быть изменён где-то в другом месте. И крутость однопоточной асинхронности заключается в том, что даже нетривиальные изменения будут внесены атомарно (если конечно не написать внутри кода внесения изменений await something()).

Тот же стейт редакса может меняться из кучи обработчиков запросов к серверу (точнее они иницируют изменения).

а вот это уже интересно, правда я бы не назвал это гонкой

Задержку можно нивелировать на любом из тех этапов, что ведут к этому коду, но декомпенсация слишком рано или слишком поздно опять приводят к отказу в авторизации, а автор этого кода сделал реализацию с помощью deferred promise Самое веселое - при реализации с помощью async await запросы периодически вновь начинают сбоить и пролетать мимо, потому что слишком много дополнительных вычислений. Реализация async с помощью генераторов например чуть быстрее, но тоже иногда падает. Где это компенсировать по прежнему не ясно. Всё крутится вокруг того кода, что я указал и пары других криптографических методов

Если хотите чистых примеров, то есть фрагмент кода, который работает (не всегда) при задержке в 100 мс и не работает при любой попытке её исправить)) Включая setImmediate и прочие очевидные варианты

я б посмотрел

Короче, гонка, это когда не понятно почему, а не как исправить. Были бы все приложения в два промиса, связываемые через all -- гонки бы точно не было)

я б посмотрел

https://github.com/zerobias/telegram-mtproto/blob/5fe3a263d2a4e6d3ed1a2472d81786da500ac66e/lib/net/encrypted-rpc-channel.js#L65 Предупреждаю, там портал в ад

P.S. Комментарий лжёт

https://github.com/zerobias/telegram-mtproto/blob/5fe3a263d2a4e6d3ed1a2472d81786da500ac66e/lib/net/encrypted-rpc-channel.js#L65 Предупреждаю, там портал в ад

поверхностный взгляд на код приводит к такому вопросу: а что если callback не определён? или такого не может быть?

то есть запихивание callback в this._callbackMap может происходить после вызова EncryptedRpcChannel.prototype._onRpcResult?

поверхностный взгляд на код приводит к такому вопросу: а что если callback не определён? или такого не может быть?

Так это же всё внутри if (callback)

ага и этот if теоретически может не сработать, то есть callback вполне может быть undefined

может в этом проблема?

Чтобы не описывать месяц экспериментов, просто скажу, что стоит ограничиться случаем, когда callback заведомо существует и if (callback) - это пожалуй единственное, на что можно положиться в этом коде

Автор знает callback hell как свой родной дом