Comments 15
Боюсь показаться глупым, но каков кейс использования сабжа?
+2
Например библиотеки по считыванию QR кода сильно тормозят main процесс при своей работе, с помощью данной библиотеки ими можно пользоваться проще.
В целом случаи когда нужны воркеры не очень часто встречаются, но неудобство их использования заставляет разработчиков искать решения без них. У нас были случаи когда пользоваться воркером удобно.
В целом случаи когда нужны воркеры не очень часто встречаются, но неудобство их использования заставляет разработчиков искать решения без них. У нас были случаи когда пользоваться воркером удобно.
0
Это кейс использования воркеров. Но почему не перенести весь необходимый код сразу в них, зачем жонглировать eval'ами?
+3
Этот подход позволяет не менять архитектуру, не настраивать особым образом сборку проекта. Легко и просто перенести любой загруженный код в воркер, не переписывая всё вокруг.
-2
Если такая проблема вынести нужные части кода в воркер — возможно, проблема как раз с архитектурой?
Нет, в принципе, я согласен, что было бы круто иметь возможность просто выполнить произвольную функцию в другом потоке. Но статья полна оговорок, примечаний и извинений. И либа, при всём уважении к вашей креативности, выглядит очень костыльно. И есть подозрение, что при дальнейшем её использовании будут найдены ещё не одни подводные грабли. Точно ли это адекватная цена за удобство?
Нет, в принципе, я согласен, что было бы круто иметь возможность просто выполнить произвольную функцию в другом потоке. Но статья полна оговорок, примечаний и извинений. И либа, при всём уважении к вашей креативности, выглядит очень костыльно. И есть подозрение, что при дальнейшем её использовании будут найдены ещё не одни подводные грабли. Точно ли это адекватная цена за удобство?
+5
Данная библиотека используется в проектах и хорошо справляется с поставленными задачами. По мере расширений требований к ней добавляется новый функционал. Самая большая проблема в ней — невозможность использования замыкания.
А что в этой библиотеке кажется вам костыльным (кроме «eval»)?
Получилась библиотека с удобным АПИ, которая позволяет
В целом я хотел получить способ удобно пользоваться многопоточностью в javascript. В каком-то виде это получилось, пользоваться или нет — личное дело каждого. Так как воркеры не особо востребованы — статья больше исследовательская, чем призыв к использованию.
А что в этой библиотеке кажется вам костыльным (кроме «eval»)?
Получилась библиотека с удобным АПИ, которая позволяет
просто выполнить произвольную функцию в другом потокеОна сырая, но только пользователи и issue на гитхабе помогут сделать её лучше.
В целом я хотел получить способ удобно пользоваться многопоточностью в javascript. В каком-то виде это получилось, пользоваться или нет — личное дело каждого. Так как воркеры не особо востребованы — статья больше исследовательская, чем призыв к использованию.
+1
Ну, с моей точки зрения воркеры — это достаточно удобная многопоточность. Настройка сборки происходит один раз. А архитектурные ограничения — повод избавиться от спагетти, разделить код на менее связанные компоненты. Если думать о том и другом заранее, то всё хорошо. Соответственно, ваш проект (согласно вашему же описанию) мне видится как некий хак, чтобы быстро впихнуть многопоточность туда, где она изначально не задумывалась.
+1
Ну описания нашего проекта в этом треде нет. Библиотека это «некий хак» для удобной работы с воркерами, я с этим согласен. На мой взгляд запуск дополнительного потока не должен требовать подготовки в виде настройки сборщика, это должен быть просто вызов асинхронного метода. Это гораздо удобнее в любой архитектуре. Это также уменьшает порог входа в данную технологию.
+1
В общем-то, я с вами согласен. И когда для этого появится механизм на уровне языка, с удовольствием им воспользуюсь при случае. Но я не хочу каждый раз, используя этот механизм, думать о том, какие ограничения есть у библиотеки, его реализующей (а они есть), и что в ней может пойти не так (а оно может). Проще настроить сборку и быть спокойным.
P.S. Ни в коем случае не имею в виду, что все должны думать так же, как я.
P.S. Ни в коем случае не имею в виду, что все должны думать так же, как я.
+1
UFO just landed and posted this here
Aingis, я не совсем понимаю в чём вопрос. Суммарное время работы кода увеличилось (не значительно, хотя это конечно зависит от объема передаваемых данных), так как нужно серриализовывать и парсить данные. Но за счёт того что обработка картинки происходит в воркере исчезло замирание интерфейса. Когда глазом перестали быть заметны тормоза — то да, я считаю что эти затраты окупаются. Возможно в дальнейшим мы добавим сущность типизированного массива, чтобы ускорить парсинг и серриализацию.
+2
В дополнение к статье) Я думаю, что весь код воркера стоит разбивать на составляющие и, тем самым, параллелить выполнение наиболее затратных операций и методов в самих воркерах. Каждому воркеру стоит назначать не более трех функций. Т.о., весь код, перенесенный в воркеры, будет значительно быстрее отрабатывать.
Т.е. можно запустить целую группу воркеров, которые, в целом, могут быть организованы так, как описывается в микросервисной архитектуре. Я, единственное, не знаю, как множество одновременно работающих воркеров будет потреблять ресурсы)))
Т.е. можно запустить целую группу воркеров, которые, в целом, могут быть организованы так, как описывается в микросервисной архитектуре. Я, единственное, не знаю, как множество одновременно работающих воркеров будет потреблять ресурсы)))
0
case MESSAGE_TYPE.ADD_LIBS:
Это артефакт копипасты? Поначалу решил, что вы собираетесь отдельно передавать в воркер новые методы.
0
Sign up to leave a comment.
Работа с Worker “как хочется“, а не “как можно”