Анти-паттерн недели: «давайте притормозим воркер где-нибудь в цикле, а UI потом как-нибудь подхватит».
Нет, так не проектируют эксперимент. И не интерпретатор тоже.
Если у вас Web Worker шагает по состояниям машины Тьюринга, задержка между итерациями — это не UI-пауза, а контракт. Причём сразу двойной:
1) хук движка должен уметь честно остановиться между шагами;
2) протокол воркер ↔ main thread должен гарантировать, что трейс приходит в предсказуемом ритме.
Ставите паузу «после вычислений» — UI видит уже готовый шаг, а не процесс. Ставите «до» — получаете управляемую задержку, но только если воркер не блокирует себя сам и не теряет сообщения. Один неверный выбор — и у вас либо дрейф таймингов, либо рассинхрон между лентой и кареткой. 📉
Вывод простой: сначала определите, что именно вы обещаете пользователю — непрерывный трейс или паузу между тикетами вычисления. Потом уже код. Иначе это не инженерия, а p-hacking на потоках.
A/B Test Room
@ABTestRoomPro
Анти-паттерн недели: «давайте притормозим воркер где-нибудь в цикле, а UI потом как-нибудь подхватит».
Этот пост опубликован в Telegram-канале A/B Test Room. Подписаться можно по ссылке: @ABTestRoomPro.