Comments 14
В 2 словах, если задача на JS занимает много времени выполнения, разбиваем её на части?
Действительно ли падает по переполнению из-за малого (нулевого) timeOut или, всё же, из-за малого stepRange, а timeOut ==0 допустимо? И какая версия IE?
Действительно ли падает по переполнению из-за малого (нулевого) timeOut или, всё же, из-за малого stepRange, а timeOut ==0 допустимо? И какая версия IE?
1. Да! Разбиваем на подзадачи и каждую вызываем асинхронно (в случае если основная задача «не прерываемая», например — цикл).
2. Вы правы! Строго говоря — падает при малом stepRange, т.е. timeOut можно выставлять в 0.
3. IE 7 и 8
2. Вы правы! Строго говоря — падает при малом stepRange, т.е. timeOut можно выставлять в 0.
3. IE 7 и 8
Про таймаут как раз был основной вопрос, потому что выставление 200мс показалось странным и была мысль: неужели какому-то старому IE это критично? Разбивание JS на части — это обычная практика давать допуск рендереру DOM и аяксу периодический доступ к обработке, и в ней достаточно указывать паузу в 0 мс (или символические 1 мс), а далее движок скрипта сам разбирается, какие задачи выполнять и какие минимальные паузы он может себе позволить.
Тоже верно. Приложения в основном стараются проектировать так, что бы можно было логически разбить JS на части. Каждая часть становиться «чистой» функцией.
А вот когда проектное решение хромает на обе ноги, и от него уже нельзя отказаться, приходится придумывать подобное этому — постепенную (последовательную) обработку цельного массива данных через равные (>0) тайм-ауты.
200мс — поставлено для наглядности.
А вот когда проектное решение хромает на обе ноги, и от него уже нельзя отказаться, приходится придумывать подобное этому — постепенную (последовательную) обработку цельного массива данных через равные (>0) тайм-ауты.
200мс — поставлено для наглядности.
Эх, если бы кто в js реализовал такую магию, как «async» в C#5, когда встречается фунция Sleep (или любая другая псевдо-блокирующая), текущая функция бы прерывалась и возвращала управление главному потоку, а после завершения псевдо-блокирующей операции (для sleep — сигнал таймера), выполнение бы продолжалось с точки прерывания без потери контекста.
JavaScript асинхронен и однопоточен — там не нужна функция Sleep
Значит, идея не понята :)
Идея в том, что пишешь алгоритм как обычно.
Но если встречается Sleep(x), то на этом функция завершается, а остаток заворачивается в аргумент setTimeout(x).
Вот такой синтаксический сахарочек, прозрачно для программера.
Идея в том, что пишешь алгоритм как обычно.
Но если встречается Sleep(x), то на этом функция завершается, а остаток заворачивается в аргумент setTimeout(x).
Вот такой синтаксический сахарочек, прозрачно для программера.
Ах, ну в этом случае да :)
nin-jin.github.com/article/article_fiber/article_fiber.doc.xml
работает в мозилле (с типом «application/javascript;version=1.7») и хроме (при включённом «экспериментальном JavaScript»)
осталось дождаться пока генераторы появятся в остальных браузерах
работает в мозилле (с типом «application/javascript;version=1.7») и хроме (при включённом «экспериментальном JavaScript»)
осталось дождаться пока генераторы появятся в остальных браузерах
> Вместе с тем, частичная обработка массива через равные промежутки времени — не блокирует основной поток выполнения программы. Что позволяет обрабатывать другие callback функции.
Нет в JavaScript потоков. И основного потока нет. Есть только текущий «контекст» исполнения — асинхронные обработчики выстраиваются в очередь и ждут пока он не закончит свою работу и переключится на следующий.
Нет в JavaScript потоков. И основного потока нет. Есть только текущий «контекст» исполнения — асинхронные обработчики выстраиваются в очередь и ждут пока он не закончит свою работу и переключится на следующий.
Однако основная проблема — разрыв соединения при обработке массива осталась.
Скажите, а если делать временные промежутки обработки еще короче, соединение все таки можно спасти?
PS. При прочтении я ошибочно думал, что задача — отсортировать массив, поэтому долго не мог понять, как Вы это сделали…
Скажите, а если делать временные промежутки обработки еще короче, соединение все таки можно спасти?
PS. При прочтении я ошибочно думал, что задача — отсортировать массив, поэтому долго не мог понять, как Вы это сделали…
Временные промежутки можно делать короче. Однако, думаю вы не правильно поняли — первоначально в коде был большой массив, внутри которого так же было много тяжелых действий. Когда IE начинал обрабатывать его, он мог «заморозиться» на неопределенное количество секунд, что чудесным образом приводило к разрыву соединения. При окончании цикла, начиналась свистопляска с пере-подключением и перерисовкой интерфейса. Одним словом — это критическое место в программе приводило к абсолютно не корректному поведению приложения.
Большой временной промежуток был специально поставлен, что бы массив (скорость обработки которого была не критична) обрабатывался очень редко и очень медленно — имулируя работу в background-е.
Таким способом отсортировать массив думаю можно, хотя это потребует некоторых изменений.
Большой временной промежуток был специально поставлен, что бы массив (скорость обработки которого была не критична) обрабатывался очень редко и очень медленно — имулируя работу в background-е.
Таким способом отсортировать массив думаю можно, хотя это потребует некоторых изменений.
Решал подобную задачу.
Функция отрисовки путей на гуглокарте подвешивала браузер для более 20 путей. Тогда для того, чтобы давать интерфейсу отрисовываться, написал асинхронный итератор по массиву. И применял его для массивов более 15 элементов.
Функция отрисовки путей на гуглокарте подвешивала браузер для более 20 путей. Тогда для того, чтобы давать интерфейсу отрисовываться, написал асинхронный итератор по массиву. И применял его для массивов более 15 элементов.
Sign up to leave a comment.
Отложенная обработка массива