Комментарии 12
А зачем?
WebWorker необходим для распараллеливания, что в свою очередь позволяет задействовать большее количество ядер. Что Теоретически (когда частота каждого ядра невысока, а нагрузка различными скриптами высока) позволяет повысить скорость работы, задействуя несколько потоков. Да и разработчики WebWorker не зря же сделали поддержку запросов?
P.S: пару раз просили помочь с подобным.
P.S: пару раз просили помочь с подобным.
XHR — да. Но помимо нее параллельно может идти множество других процессов. XHR не особо требователен к CPU, но ведь и в WebWorker его зачем-то добавили. А для простоты разработки могли бы и не добавлять — WebWorker итак имеет много ограничений, могли бы добавить и еще +1 ограничение.
В любом случае, раз был интерес к этой теме со стороны различных людей, то зачем-то им это надо?
В любом случае, раз был интерес к этой теме со стороны различных людей, то зачем-то им это надо?
Было подобное: habrahabr.ru/post/132785/
Хотя конечно любые полезные начинания — это хорошо.
З.Ы. Подправьте своё написание кода, хотя бы для статьи, а то жуть просто.
Хотя конечно любые полезные начинания — это хорошо.
З.Ы. Подправьте своё написание кода, хотя бы для статьи, а то жуть просто.
Как выше написали, работа с сетью в js не cpu intensive, специально выделять ее в воркеры не нужно. А поддержку xhr из webworkers сделали потому что это может кому-нибудь понадобиться. Например вы качаете много данных, а потом делаете много cpu intensive действий с ними. Проще будет написать всю эту логику в воркере, а не качать данные отдельно в основном потоке, чтобы потом отправить их в воркер.
Так что делать как указано в статье не стоит. Сложно и незачем.
Так что делать как указано в статье не стоит. Сложно и незачем.
Первое, если стоит сложный обработчик запросов, то он как минимум будет выполнять фоном свою работу — если получил ошибку от сервера, обработал, если что заново послал запрос и так далее. Если запросов много это скажется, хоть и незначительно. Второе. Если в одном потоке сразу несколько запросов и их надо либо сравнивать, либо производить какие-либо действия, к примеру, математические. Тогда запрос становится весьма тяжелым. Например, запросом считывается параметры векторов, которые потом обрабатываются в этом же потоке. Или же делается 10 запросов, которые либо сравниваются, либо подставляются в различные формулы. То есть параллельный поток создается не для запроса, а для вычислений, а запрос уже как вторичная задача, дескать, подхватить нужные данные для расчета. В таком случае — расчет весьма затратный по времени, делать его в основном потоке уже неактуально, поэтому и запрос проще сделать в фоновом расчете — там же, где и расчет. В итоге, можно запустить несколько фоновых расчетов со своими запросами. Можно сделать и наоборот — запрос в основном потоке, и пересылать результаты запроса через postMessage в поток — но тогда это усложнение, так как проще сделать запрос в том месте, где нужны эти данные.
Предположим по результатам тех или иных расчетов должен произойти тот или иной запрос, после которого пойдут дальше расчеты. Если запрос будет сделан в основном потоке, то необходимы постоянные пересылки туда-сюда данных. Если запрос сделан в фоновом потоке, где и производится расчет, то никаких пересылок не надо.
А разве XmlHttpRequest не работает сам по себе в отдельном потоке? А если его запустить из WebWorker-а, то будет ли он создавать отдельный поток для запроса или будет работать в том же? Если будет создавать отдельный, то не затратно ли это по два потока на запрос? Не эффективнее ли было бы посылать запрос из основного потока, а обрабатывать ответ в воркере?
Нет. Не работает.
Опять же. Если по результатам расчетов надо делать тот или иной запрос — зачем 100 раз делать пересылки из основного потока в ВебВоркер? А так, идет расчет в фоновом потоке, если нужно ему нужно подгрузить данные, он их сам и подгружает без излишних переселок.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Скрещиваем WebWorker и XMLHttpRequest