Я понимаю, почему разработчики браузеров не хотят, чтобы я блокировал их поток пользовательского интерфейса. Однако я не понимаю, почему есть:
Существует синхронный API файловой системы . Существует также синхронный IndexedDB API. Для меня это кажется противоречием.
Поскольку V8 реализовал ES2017 await/async, я могу использовать это с библиотеками с поддержкой Promise, и мне не нужен синхронный API так плохо.
Причина, по которой нет функции sleep(), доступной для WebWorkers, проста: вам это не нужно. sleep является синхронной функцией (она блокирует до тех пор, пока она не вернется), что не имеет смысла в асинхронном контексте WebWorkers.
Если вы отправляете сообщение в WebWorker, он не блокирует ожидание ответа; ответ отправляется как сообщение функции вашего обработчика сообщений. Если вы хотите подождать определенное количество времени перед отправкой ответа, вы не будете использовать sleep, вы должны использовать setTimeout и вызывать сообщение при вызове функции.
Аналогично, если вы используете передачу данных WebWorkers для WebSocket, вы получите сообщение из основного потока, асинхронно отправляете пакет через websocket, а затем в обработчике ответа вы отправляете сообщение обратно в основной поток, Нет логичного места для использования синхронной функции sleep.
Насколько нет синхронного режима для таких Web-сокетов, как для файловой системы, основное отличие заключается в том, что файловая система не доступна по сети. Как правило, асинхронные API-интерфейсы предпочтительнее для сетевых функций, поэтому, я думаю, я не вижу в этом столько противоречий.
IDB поддерживается только тремя браузерами, ни один из которых не реализовал синхронный API, поэтому я не вижу в этом яркого примера синхронных API. Inf факт, я думаю, что противоречие, что люди будут определять API и не потрудились его реализовать.
Это не очевидно: протокол TCP также является сетевым протоколом, верно? И он довольно часто используется в синхронном режиме, поскольку он упрощает разработку приложений и отлаживает их.
На мой взгляд, режим Async очевиден в контексте приложений с монопотоком, когда вы не хотите, чтобы I/O блокировал пользовательский интерфейс. Это очень малополезно, если вы намерены использовать веб-работников, например, для обработки фоновых операций ввода-вывода. Было бы действительно удобно иметь синхронный Websocket в соединении с веб-рабочими.
Наконец, просто не стоит считать, что вызов чтения файла будет выполнен и быстро. У вас всегда должен быть тайм-аут или принять тот факт, что ваше приложение будет зависать, если IO не отвечает.
Для меня это совершенно очевидно.
API FileSystem и IndexedDB API работают в порядке миллисекунд, поэтому вы можете доверять своим данным прямо сейчас, вместо этого API WebSockets должен быть как минимум в 100 раз медленнее, данные должны лететь над диким интернетом, поэтому очевидно, что он будет асинхронным. Ваш ответ может даже не вернуться.
Индексированный db не будет блокировать выполнение в течение более длительного времени, скорее всего, он даст результат в несколько миллисекунд, и мы не ожидаем хранить миллионы записей в индексированном db. То же самое с файловым API, большинство API приведет к более быстрому выполнению.
Также синхронный API приведет к условиям гонки и потребует многопоточной синхронизации и т.д., что увеличит сложность программирования. Вместо потоковой передачи на основе сообщений проще программировать, и у нас нет проблем с синхронизацией.
Также большинство движков javascript стабильны, и люди знакомы с асинхронными способами программирования. Это проще и только способ написать работника. Для изменения этого потребуется огромная переработка javascript-движков. Внедрение более родного API усложнит программирование рабочих. Различные ОС и другая архитектура или устройства wiki представляют большую сложность.