Как предотвратить блокировку веб-работников HTML5, чтобы они правильно отвечали на сообщения от родителей
Я использую веб-работников для выполнения некоторых нагрузок на процессор, но у меня есть требование, чтобы работник отвечал на сообщения из родительского сценария, пока работник еще обрабатывает.
Однако работник не будет отвечать на сообщения, пока он заблокирован в цикле обработки, и я не нашел способа опроса очереди сообщений. Таким образом, кажется, что единственное решение состоит в том, чтобы прерывать обработку с интервалом, позволяющим обслуживать любые сообщения в очереди.
Очевидные варианты - использовать таймер (скажем, с setInterval), однако я прочитал, что минимальная задержка между срабатываниями довольно велика ( http://ajaxian.com/archives/settimeout-delay), что, к сожалению, замедляет обработку много.
Что думают об этом другие народы? Я собираюсь попробовать рабочую отправку onmessage к себе в конце каждого onmessageтаким образом, эффективно реализуя один шаг цикла обработки для каждого события, полученного от самого себя, но просто хотел посмотреть, есть ли у кого-нибудь какие-либо идеи по этому поводу.
Спасибо,
3 ответа
Рабочий может порождать субработников. Ваш основной работник может выступать в качестве очереди сообщений, а когда он получает запрос на длительную операцию, порождает подчиненного для обработки этих данных. Затем подчиненный может отправить результаты обратно основному работнику, чтобы удалить событие из очереди и вернуть результаты в основной поток. Таким образом, ваш основной работник всегда будет свободен для прослушивания новых сообщений, и вы сможете полностью контролировать очередь.
--Ник
Я сам столкнулся с этим вопросом, когда впервые играл с рабочими. Я также обсуждал использование setInterval, но чувствовал, что это будет довольно хакерский подход к проблеме (и я уже пошел по этому пути для своей эмулированной многопоточности). Вместо этого я остановился на работниках из основного потока (worker.terminate()) и воссоздал их, если задача, в которую они вовлечены, должна быть прервана. Сборка мусора и т. Д., Казалось, была обработана в моем тестировании.
Если есть данные из этих задач, которые вы хотите сохранить, вы всегда можете отправить их обратно в основной поток для хранения через регулярные промежутки времени, и если есть какая-то логика, которую вы хотите реализовать относительно того, завершены ли они или нет, вы можете опубликовать соответствующие данные возвращаются через достаточно регулярные интервалы, чтобы это было возможно.
В любом случае, порождение субработников приведет к тому же набору проблем; вам все равно придется прекратить субработников (или создавать новых) в соответствии с некоторой логикой, и я не уверен, что это также хорошо поддерживается (например, в Chrome).
Джеймс
Имея ту же проблему, я искал черновик веб-работников и нашел что-то в разделе Модель обработки, шаги с 9 по 12. Насколько я понял, работник, который начинает обрабатывать задачу, не будет обрабатывать другую задачу до тех пор, пока не выполнится первая. Таким образом, если вы не заботитесь о том, чтобы остановить и возобновить задачу, ответ nciagra должен дать лучшую производительность, чем перепланирование каждой итерации задачи.
Все еще расследую, хотя.