#1 DOM в WebWorker? Как? - Многопоточность и DOM

alert/prompt можливо блокуe чергу. Iлья, дякую за вiдео

Решается через синхронный XmlHhttpRequest делаем запрос перехватываем его держим открытым и параллельно делаем свои асинхронные делишки.

Сделать бесконечный цикл, который будет проверять пришло ли ответное сообщение, только тогда надо будет использовать этот sharedArrayBuffer объект. Хз, мне кажется может получиться

А куда идти за пирожком?)

Очень круто, спасибо за видео!

Очень умный парень, очень много делает для всех, надеюсь ума хватит, чтоб не загребли и не отправили в мясорубку

Похорошел кстати

Берегите себя Илья!

а куда пропал мой коммент где я описал один из способов?

. while(true) // ждём ответа
Это анти-паттерн в основном потоке , но в воркерах, почему бы и нет? Конечно же с точки зрения cpu неэффективно и батарейку будет жрать только в путь, но кого это волнует в наше время))

Уууу... ну поток блокируется бесконечным циклом хорошо :) можно просто сделать while(waitForReply) какой-нибудь и он должен подвешать поток. А внутри цикла как-то проверять новые сообщения от основного потока в надежде что придет то самое сообщение и разблочит поток. Не знаю даже как еще можно "приостановить" поток. Но сомнительно что бесконечные циклы в фоне хорошая идея. И не совсем понятно как изнутри цикла который заблокировал поток будут выполняться те же слушатели для postmessage. По идее никак если поток блокирован.Такая себе идея получается.

Еще думал про какую-нибудь shared memory между основным потоком и воркером чтобы сделать операцию синхронной. Можно было бы в эту сторону покопать.

cliff hanger это ты конечно хорошо придумал, заставляет хотя бы немножко подумать над решением, что лучше чем просто его сразу узнать с точки зрения получения информации

Запустить вызов микротасков бесконечно в зависимости от флага. Потом когда получили обраный ответ снять флаг.

while c pointer?

А если в функцию добавить setTimeout которая вызывает эту же функцию до тех пор, пока операция не завершилась

Сорян, но произношение слов width, height, query - боль.

До конца не додумал мысль, но вариант такой: под капотом async у нас promise и генераторы. Поэтому возможно что-то похожее.

Если я не ошибаюсь, запуск скриптов в Worker'е с проксированием DOM умела ещё AMP

Крутить while в котором проверять что в SharedArrayBuffer появилось значение, которое записывать из основного потока?

Спустя пару минут гугления, нашел вот такую штуку: Atomics.wait(), которая позволяет синхронно подождать какой то таймаут. Т.е. мы можем "уснуть" на какое то время, и потом проверить, а не пришло ли уже значение из главного треда. Звучит как рабочий вариант. Ну и еще из глупого решения - сделать бесконечный while, который будет грузить cpu.

Тупой способ это проверка шаредбуфера в вайле. Продвинутый тоже самое, но на бэке делаем апи которые отвечает ровно через сек, а в вайле дергаем эту апи синхронным XHR.

Только сегодня вспоминал Вас, давно видео не было, начал волноваться... Берегите себя.

Вероятно в итоге все равно потребуется обменяться SharedArrayBuffer и повесить мьютекс на функцию работающую с DOM. Если код из WW хочет получить offsetWidth, а затем, основываясь на этом значении что-то сделать с DOM - эта операция должна быть атомарной (что, если другой поток поменяет ширину элемента в промежутке между обменом сообщениями). Главный поток гарантирует нам атомарность при работе с DOM, а рассмотренном случае мы ее теряем.

Треба м'ютекс реалізований через shared array buffer, як Тимур реалізовував тут https://www.youtube.com/watch?v=JNLrITevhRI

Кроме генераторов в джс ничего нет пока , чтоб это сделать адекватно

Как заблокировать эвентлуп? Через микротаски!

yield

Спасибо что контент снова на русском. Астрологи предсказывают увеличение аудитории в 10 раз

Atomics.wait() ??

Можно топорно заблокировать бесконечным циклом с проверкой (прощай CPU). Вообще как то пробовал делать что то похожее на sleep при синхронном исполнении.

Очень актуальная тема. Жду продолжения. Как заблокировать эвентлуп, хотя бы одним из способов, понятно, интересно как его потом разблокировать.

Если потоки могут обмениваться объектами, значит воркер может просто запросить объект, поставить блокировку на изменение этого объекта в основном потоке, сделать всё что нужно и вернуть объект в основной поток сняв блокировку с него. Зачем блокировать эвентлуп?

❤️

Занятно. Спасибо.

Илья, спасибо вам большое за ваш вклад в сообщество! Вы прекрасный человек и специалист! Здоровья вам и мира этому миру!

Яка ситуація у Харкові? Привіт з Франківська)

ответ наверное генераторы?
так как это единственное что приходит на ум

интригант )))