¿Por qué no hay soporte WebSocket síncrono en Web Workers cuando hay soporte de sistema de archivos síncrono?

La razón por la que no hay una función sleep() disponible para WebWorkers es simple: no la necesita. sleep es una función síncrona, (se bloquea hasta que regresa) que no tiene sentido en el contexto asíncrono 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 gestor de mensajes. Si desea esperar una cierta cantidad de tiempo antes de enviar una respuesta, no usaría sleep, use setTimeout y dispare un mensaje cuando se llame a su función.

Del mismo modo, si está utilizando WebWorkers para la transmisión de datos WebSocket, recibiría un mensaje del hilo principal, enviaría un paquete a través de websocket de forma asíncrona, luego en el manejador de respuestas enviaría un mensaje al hilo principal. No hay lugar lógico para usar una función síncrona sleep.

En cuanto a por qué no hay un modo síncrono para WebSockets como lo hay para el sistema de archivos, el principal la diferencia es que el sistema de archivos no se accede a través de la red. En general, las API asíncronas son preferibles para las funciones basadas en red, por lo que supongo que no lo veo como una gran contradicción.

El BID solo es compatible con 3 navegadores, ninguno de los cuales ha implementado la API síncrona , por lo que no lo veo como un brillante ejemplo de API síncronas. De hecho, creo que esa es la contradicción que la gente definiría una API y no se molestaría en implementarla.

No es obvio en absoluto : protocolo TCP es un protocolo de red también, ¿verdad ? Y se usa muy a menudo en modo síncrono, porque hace que las aplicaciones sean más fáciles de desarrollar y depurar.

En mi opinión, el modo asíncrono es obvio en el contexto de las aplicaciones mono threaded, cuando no desea que las E/S bloqueen una interfaz de usuario. Es mucho menos obivoso si tiene la intención de utilizar web workers, por ejemplo, para manejar E/S en segundo plano. De hecho, sería conveniente tener Websocket síncrono en conjunción con web workers.

Finalmente, simplemente no es carful asumir que una llamada de lectura de archivo se hará y rápidamente. Siempre debe tener un tiempo de espera o aceptar el hecho de que su aplicación se va a colgar si IO no responde.

Para mí es bastante obvio.

FileSystem API & IndexedDB API funciona en orden de milisegundos para que pueda confiar en tener sus datos ahora mismo, en su lugar, WebSockets API debe ser al menos 100 veces más lento, los datos deben volar sobre el internet salvaje, por lo que es obvio que sea asíncrono. Tu respuesta nunca puede responder.

La base de datos indexada no bloqueará la ejecución durante más tiempo, lo más probable es que dé resultado en pocos mili segundos y no esperamos almacenar millones de registros en la base de datos indexada. Lo mismo con la API de archivos, la mayoría de la API resultará en una ejecución más rápida.

También la API síncrona conducirá a condiciones de carrera y requerirá sincronización de subprocesos múltiples, etc., lo que aumentará la complejidad de la programación. En cambio, el enhebrado basado en mensajes es más fácil de programar y estamos libres de problemas de sincronización.

También la mayoría de los motores javascript son estables, y la gente está familiarizada con las formas de programación asíncrona. Es más fácil y la única manera de escribir trabajador. Cambiar esto requerirá una gran reescritura de los motores javascript. La introducción de más API nativa hará que la programación del trabajador sea más complicada. Diferentes sistemas operativos y diferentes arquitecturas o dispositivos wiki introducen más complejidad.