Javascript: Как в javascript реализовано несколько потоков? - PullRequest
0 голосов
/ 06 мая 2020

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

В нескольких местах я читал, что javascript не поддерживает многопоточность. Тогда какое может быть возможное решение для двусторонней связи, поскольку для параллельного управления связью C1-> C2 и C2-> C1 потребуются два потока.

Моя высокоуровневая архитектура выглядит как

enter image description here

Как с помощью javascript можно управлять тремя потоками на веб-странице? Один для передачи сообщений C1 в C2, второй для передачи сообщений C2 в C1 и третий для пользовательского интерфейса?

1 Ответ

2 голосов
/ 06 мая 2020

Программа JavaScript выполняется в одном потоке выполнения с использованием семанти «выполнить до завершения» c.

Операции, которые обычно блокируются на других языках, являются неблокирующими и просто передаются к хосту (в данном случае браузеру), при этом ваша программа получает уведомление о прогрессе асинхронно через события.

Когда хост генерирует событие, которое будет обработано вашей программой (например, входящее сообщение), он помещает уведомление об этом событии в очереди как «задание». Когда это задание достигает начала очереди и как только стек вызовов становится пустым (ie. Текущий выполняемый скрипт завершился), среда выполнения JavaScript удаляет задание из очереди и вызывает функцию продолжения, связанную с it (ie. часть вашей программы, сконфигурированная для обработки события).

Ваша игра будет отправлять сообщения по сети (например, через WebSocket). Ваша программа просто передает каждое сообщение в браузер. Этот процесс не требует больших вычислительных ресурсов и времени. Браузер является многопоточным и решит за вас низкоуровневые и трудоемкие сетевые проблемы.

JavaScript - это язык, основанный на событиях. Если вы будете sh получать уведомления о будущих событиях, связанных с отправленным вами сообщением, вы можете предоставить обратный вызов (или использовать обещание), который будет вызываться средой выполнения в будущем в соответствующее время, а не просто ждать Это. Таким образом, время, доступное в основном потоке выполнения, используется эффективно.

Ваша игра l oop, вероятно, будет использовать requestAnimationFrame. Это дает вам около 16 миллисекунд вычислений на кадр. Вычисление состояния игры может занять несколько миллисекунд. Обработка запланированных и привязанных ко времени событий может занять еще несколько миллисекунд. Наконец, рендеринг тоже требует некоторого времени. По сути, ваша программа совместно выполняет несколько задач в одном потоке выполнения.

Для длительных, вычислительно затратных задач вы можете использовать Worker API для создания новых потоков выполнения, с которыми вы может общаться контролируемым образом, но, вероятно, вам здесь это не понадобится.

В сети уже много информации об этом c. Найдите "как работает событие l oop".

Соответствующие вопросы здесь , здесь , здесь , здесь и здесь .

...