Комментарии 15
Боюсь показаться глупым, но каков кейс использования сабжа?
Например библиотеки по считыванию QR кода сильно тормозят main процесс при своей работе, с помощью данной библиотеки ими можно пользоваться проще.
В целом случаи когда нужны воркеры не очень часто встречаются, но неудобство их использования заставляет разработчиков искать решения без них. У нас были случаи когда пользоваться воркером удобно.
В целом случаи когда нужны воркеры не очень часто встречаются, но неудобство их использования заставляет разработчиков искать решения без них. У нас были случаи когда пользоваться воркером удобно.
Это кейс использования воркеров. Но почему не перенести весь необходимый код сразу в них, зачем жонглировать eval'ами?
Этот подход позволяет не менять архитектуру, не настраивать особым образом сборку проекта. Легко и просто перенести любой загруженный код в воркер, не переписывая всё вокруг.
Если такая проблема вынести нужные части кода в воркер — возможно, проблема как раз с архитектурой?
Нет, в принципе, я согласен, что было бы круто иметь возможность просто выполнить произвольную функцию в другом потоке. Но статья полна оговорок, примечаний и извинений. И либа, при всём уважении к вашей креативности, выглядит очень костыльно. И есть подозрение, что при дальнейшем её использовании будут найдены ещё не одни подводные грабли. Точно ли это адекватная цена за удобство?
Нет, в принципе, я согласен, что было бы круто иметь возможность просто выполнить произвольную функцию в другом потоке. Но статья полна оговорок, примечаний и извинений. И либа, при всём уважении к вашей креативности, выглядит очень костыльно. И есть подозрение, что при дальнейшем её использовании будут найдены ещё не одни подводные грабли. Точно ли это адекватная цена за удобство?
Данная библиотека используется в проектах и хорошо справляется с поставленными задачами. По мере расширений требований к ней добавляется новый функционал. Самая большая проблема в ней — невозможность использования замыкания.
А что в этой библиотеке кажется вам костыльным (кроме «eval»)?
Получилась библиотека с удобным АПИ, которая позволяет
В целом я хотел получить способ удобно пользоваться многопоточностью в javascript. В каком-то виде это получилось, пользоваться или нет — личное дело каждого. Так как воркеры не особо востребованы — статья больше исследовательская, чем призыв к использованию.
А что в этой библиотеке кажется вам костыльным (кроме «eval»)?
Получилась библиотека с удобным АПИ, которая позволяет
просто выполнить произвольную функцию в другом потокеОна сырая, но только пользователи и issue на гитхабе помогут сделать её лучше.
В целом я хотел получить способ удобно пользоваться многопоточностью в javascript. В каком-то виде это получилось, пользоваться или нет — личное дело каждого. Так как воркеры не особо востребованы — статья больше исследовательская, чем призыв к использованию.
Ну, с моей точки зрения воркеры — это достаточно удобная многопоточность. Настройка сборки происходит один раз. А архитектурные ограничения — повод избавиться от спагетти, разделить код на менее связанные компоненты. Если думать о том и другом заранее, то всё хорошо. Соответственно, ваш проект (согласно вашему же описанию) мне видится как некий хак, чтобы быстро впихнуть многопоточность туда, где она изначально не задумывалась.
Ну описания нашего проекта в этом треде нет. Библиотека это «некий хак» для удобной работы с воркерами, я с этим согласен. На мой взгляд запуск дополнительного потока не должен требовать подготовки в виде настройки сборщика, это должен быть просто вызов асинхронного метода. Это гораздо удобнее в любой архитектуре. Это также уменьшает порог входа в данную технологию.
В общем-то, я с вами согласен. И когда для этого появится механизм на уровне языка, с удовольствием им воспользуюсь при случае. Но я не хочу каждый раз, используя этот механизм, думать о том, какие ограничения есть у библиотеки, его реализующей (а они есть), и что в ней может пойти не так (а оно может). Проще настроить сборку и быть спокойным.
P.S. Ни в коем случае не имею в виду, что все должны думать так же, как я.
P.S. Ни в коем случае не имею в виду, что все должны думать так же, как я.
Sirion, сам с нетерпением жду поддержки этого на уровне языка.
НЛО прилетело и опубликовало эту надпись здесь
Aingis, я не совсем понимаю в чём вопрос. Суммарное время работы кода увеличилось (не значительно, хотя это конечно зависит от объема передаваемых данных), так как нужно серриализовывать и парсить данные. Но за счёт того что обработка картинки происходит в воркере исчезло замирание интерфейса. Когда глазом перестали быть заметны тормоза — то да, я считаю что эти затраты окупаются. Возможно в дальнейшим мы добавим сущность типизированного массива, чтобы ускорить парсинг и серриализацию.
В дополнение к статье) Я думаю, что весь код воркера стоит разбивать на составляющие и, тем самым, параллелить выполнение наиболее затратных операций и методов в самих воркерах. Каждому воркеру стоит назначать не более трех функций. Т.о., весь код, перенесенный в воркеры, будет значительно быстрее отрабатывать.
Т.е. можно запустить целую группу воркеров, которые, в целом, могут быть организованы так, как описывается в микросервисной архитектуре. Я, единственное, не знаю, как множество одновременно работающих воркеров будет потреблять ресурсы)))
Т.е. можно запустить целую группу воркеров, которые, в целом, могут быть организованы так, как описывается в микросервисной архитектуре. Я, единственное, не знаю, как множество одновременно работающих воркеров будет потреблять ресурсы)))
case MESSAGE_TYPE.ADD_LIBS:
Это артефакт копипасты? Поначалу решил, что вы собираетесь отдельно передавать в воркер новые методы.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Работа с Worker “как хочется“, а не “как можно”