Комментарии 13
Отличная статья, хочется увидеть более реальные примеры, а то так на ум ничего не приходит…
Интересно смотреть как рожденного ползать пытаются заставить летать.
Личный опыт показал, что если задача требует многопоточности сразу переходить с javascript и не мучать себя. Вариантов много.
У меня остался вопрос, а с планировщиком что-то порешали? На сколько я помню, главный поток из-за планировщика являлся узким местом.
Однако, все сложилось так, что простой обмен данными между основным потоком и воркерами через postMessage имеет свои ограничения и может быть недостаточно хорошим для некоторых задач.
Какие ограничения, почему недостаточно хороший, для каких задач? Какую проблему вы решаете в статье?
Только у меня упоминание "Cross-Origin-Opener-Policy" в этой статье вызывает вопросы? Кто-то не почистил ответ чатжпт?
Почему вызывает?
Certain features depend on cross-origin isolation
Certain features like SharedArrayBuffer
objects or Performance.now()
with unthrottled timers are only available if your document has a COOP header with the value same-origin
set.
Ну вот в доках конкретно написано на что заголовок влияет. А тут в статье не понятно. Может я поиграться хочу, нужно мне думать про embedding и защищаться?
В перспективе может где-то и пригодиться. Спасибо за статью!
Можно применить для реализации загрузки всяких метрик и тп? А то всякие pagespeed ругаются на это)
Многопоточность JavaScript с SharedArrayBuffer и Atomics: основы