javascript - descargar - ¿Por qué no hay soporte síncrono de WebSocket en Web Workers cuando hay soporte sincrónico FileSystem?
javascript basic (5)
Entiendo por qué los proveedores de navegadores no quieren ayudarme a bloquear su subproceso de interfaz de usuario. Sin embargo, no entiendo por qué hay:
- no dormir (2) en Web Workers
- sin API síncrona de WebSockets
Hay una API de FileSystem sincrónica . También hay una API IndexedDB sincrónica . Para mí, parece una contradicción.
Dado que V8 ha implementado ES2017 await / async , puedo usarlo con bibliotecas habilitadas para Promise, y ya no necesito la API síncrona.
El db indexado no bloqueará la ejecución por más tiempo, lo más probable es que dé resultado en pocos mili segundos y no esperamos almacenar millones de registros en db indexado. Lo mismo con API de archivo, la mayoría de API dará como resultado una ejecución más rápida.
Además, la API síncrona generará condiciones de carrera y requerirá sincronización de múltiples hilos, etc., lo que aumentará la complejidad de la programación. En cambio, el enrutamiento basado en mensajes es más fácil de programar y no tenemos problemas de sincronización.
Además, la mayoría de los motores de JavaScript son estables y las personas están familiarizadas con las formas de programación asíncronas. Es más fácil y única forma de escribir trabajador. Cambiar esto requerirá una gran reescritura de los motores de JavaScript. La introducción de más API nativa hará que la programación de los trabajadores sea más complicada. Diferentes sistemas operativos y diferentes arquitecturas o dispositivos wiki introducen más complejidad.
La razón por la cual no hay una función sleep() disponible para WebWorkers es simple: no la necesita. sleep es una función sincrónica, (bloquea hasta que vuelve) lo que no tiene sentido en el contexto asincrónico de WebWorkers.
Si envía un mensaje a un WebWorker, no bloquea la espera de una respuesta; la respuesta se envía como un mensaje a su función de manejador de mensajes. Si desea esperar una cierta cantidad de tiempo antes de enviar una respuesta, no utilizaría el modo de sleep , usaría setTimeout y dispararía un mensaje cuando se llame a su función.
Del mismo modo, si está utilizando WebWorkers para la transmisión de datos WebSocket, recibirá un mensaje del hilo principal, enviará un paquete a través de websocket de forma asíncrona, y luego en el controlador de respuesta le devolverá un mensaje al hilo principal. No hay un lugar lógico para usar una función de sleep sincrónica.
En cuanto a por qué no hay un modo síncrono para WebSockets como lo hay para el sistema de archivos, la principal diferencia es que no se accede al sistema de archivos a través de la red. En general, las API asíncronas son preferibles para las funciones basadas en red, así que supongo que no lo veo como una contradicción.
BID solo es compatible con 3 navegadores, ninguno de los cuales ha implementado la API síncrona , por lo que no veo eso como un brillante ejemplo de API síncronas. De hecho, creo que esa es la contradicción de que las personas definan una API y no se molesten en implementarla.
No es nada obvio: el protocolo TCP también es un protocolo de red, ¿no? Y a menudo se usa en modo síncrono, porque hace que las aplicaciones sean más simples de desarrollar y depurar.
En mi opinión, el modo Async es obvio en el contexto de las aplicaciones mono enhebradas, cuando no desea que las E / S bloqueen una IU. Es menos obvio si tiene la intención de usar trabajadores web, por ejemplo, para manejar las E / S de fondo. De hecho, sería conveniente tener Websocket sincrónico en conjunción con los trabajadores de la web.
Finalmente, no es muy diligente suponer que se realizará una llamada de lectura de archivos y de forma rápida. Siempre debe tener un tiempo de espera o aceptar el hecho de que su aplicación se bloqueará si IO no responde.
Para mí es bastante obvio.
FileSystem API y IndexedDB API funcionan en orden de milisegundos para que pueda confiar en sus datos ahora, en su lugar, WebSockets API debe ser al menos 100 veces más lenta, los datos deben volar sobre Internet salvaje, por lo que es obvio hacerlo asincrónico. Tu respuesta nunca puede volver atrás.