JavaScript Multi Threading

10

Bueno, en estos días, JavaScript es el jugador principal en todas las tecnologías de desarrollo web, en el lado del cliente para mejorar la interfaz de usuario, la lógica del lado del cliente, en algunos servidores web como la lógica del lado del servidor también

Agregue a eso el hecho de que las personas (al menos algunas de ellas) comenzaron a moverse en el desarrollo de juegos web de flash a javascript y HTML5

¡No es hora de que admita subprocesos múltiples! ¿Existen navegadores que permiten que JavaScript sea multiproceso o existe en algún estándar, HTML5 o versiones futuras?

— Ali
fuente

1

La gente no hace cosas que no se requieren. Las personas que han contribuido en el diseño de Javascript también son las que están relacionadas con los servidores web y los navegadores que se están desarrollando para que lo supieran. Se trata de utilidad.

— Dipan Mehta

9

El subprocesamiento múltiple no se realizará en EcmaScript, pero puede exponerse en entornos host.

Los ejemplos clásicos son WebWorkers, que le permite activar un trabajador en segundo plano para trabajar y abusar <iframe>de él como una forma de generar nuevos procesos.

Cabe señalar que no es necesario el subprocesamiento múltiple en JavaScript (hay excepciones, principalmente programas relacionados con gráficos). No necesita múltiples subprocesos, ya tiene un bucle de eventos para su GUI y su representación gráfica (lienzo) está acelerada por hardware (lo que significa que la GPU renderiza sus gráficos en paralelo para usted).

Aunque proyectos como webcl son bastante emocionantes.

— Raynos
fuente

2

¿Puedes ampliar el hecho de que "no es necesario"? Me encontré con una instancia recientemente donde el caso natural en la programación de escritorio sería generar un hilo para manejar la tarea, pero obviamente esa no era una opción fácil o estándar. Trabajé en ese caso, pero generar un hilo parecía ser la solución más elegante.

— Plataforma

@rig ¿Cuál fue el caso que estabas tratando de manejar?

— Zachary K

@Rig da un ejemplo concreto. el procesamiento computacionalmente costoso es raro en JavaScript del lado del cliente

— Raynos

@Raynos, explique más sobre cómo no es necesario, solo estoy pensando que no estoy seguro de que en el desarrollo del juego, por ejemplo, si hay un gran cálculo en gráficos y en física y la velocidad de fotogramas lógicos se verá afectada fácilmente si no hay múltiples subprocesos, creo

— Ali

@ Ali, me salí y dije que hay excepciones. Sin embargo, la mayor parte de ese cálculo pesado debe darse a la GPU a través de la API de gráficos acelerados por hardware

— Raynos

4

NO

El subprocesamiento múltiple es una de las cosas más difíciles de hacer en el software. Hay demasiados casos de esquina que son realmente difíciles de resolver cuando su código no es determinista. (Estoy hablando de subprocesos múltiples con cerraduras, etc.). Además, todas las diversas bibliotecas de JavaScript se basan en el supuesto de que no es multiproceso.

Dicho esto, hay trabajadores web que le brindan un marco basado en actores para realizar operaciones de tipo de procesamiento múltiple. Puede crear trabajadores y pasar datos de un lado a otro a través de eventos.

EDITAR: La otra razón es que cuando se creó JavaScript, se hizo con la suposición de que se usaría para tareas pequeñas, por lo que no se incluyó concurrencia. Al actualizarlo ahora se rompería una gran cantidad de código. Al agregar trabajadores web, ha sido posible tener un sistema donde hay concurrencia sin memoria compartida, pero al usar actores, un modelo de concurrencia que ha demostrado ser muy robusto en varios otros idiomas como Erlang, Scala, Clojure etc.

(SI no puede decir que realmente no me gusta la concurrencia basada en bloqueo)

— Zachary K
fuente

1

Multi threading is one of the hardest things in software to get right.- ¡Solo me sorprendió con esto! El navegador que está utilizando, el sistema operativo de su escritorio, el servidor web que sirve esta página, prácticamente todas las aplicaciones que utiliza todos los días son multiproceso. ¿ESTÁS SEGURO DE QUE LO SIGNIFICA? Sin embargo, para despreciarlo, pero lo haré si dicemultithreading is not done because it is hard

— Dipan Mehta

3

@DipanMehta multi threading es una de las cosas más difíciles de hacer en el software. La razón por la que todas esas aplicaciones lo usan es porque están escritas por personas realmente talentosas

— Raynos

@Raynos - ¡Dios mío! ¡Entonces me estás llamando talentoso! Lo uso todos los días ... creo que cuando estás programando en C o cualquier aplicación a gran escala, es bastante común. El punto es que, independientemente del uso y los requisitos, el consorcio W3C realmente no lo ahorró para Javascript porque era demasiado difícil .

— Dipan Mehta

2

Su comprensión severa de lo difícil que es escribir programas paralelos correctos y eficientes. Pero el subprocesamiento múltiple no está en JavaScript debido a su complejidad innecesaria (la cosa se escribió en 3 semanas)

— Raynos

2

@DipanMehta consigue una concurrencia basada en bloqueo bien hecha, y clavar todos los casos de esquina es un problema difícil. Por ejemplo, una implementación de algo tan simple como una cola con bloqueos que se puede demostrar que es correcta en todos los casos habría sido un resultado publicable hasta hace unos años. Pero lo más importante es tratar de adaptar eso a un idioma que no lo ha tenido es pedir problemas.

— Zachary K

3

abrir javascript para multihilo creará más problemas de los que resuelve:

la arquitectura actual está basada en eventos de un solo subproceso (se ejecuta en el hilo de la interfaz de usuario con más frecuencia), en otras palabras, con cada bloque de código puede estar seguro de que nada en el entorno cambiará de principio a fin, excepto lo que se cambia en el código

tan pronto como permita la ejecución preferente o la ejecución paralela, esta función desaparecerá, esto significa que debe aplicar bloqueos a los datos que desea mutar, además de tener todas las condiciones de carrera difíciles de depurar para evitar

es posible tener una ejecución pseudo-paralela usando tiempos de espera, esto significa dividir las funciones grandes o largas en trozos atómicos y usar setTimeout(function(){nextstep(args);},1);para que otras cosas puedan ejecutarse si es necesario

— monstruo de trinquete
fuente

0

Intel lanzó River Trail hace algún tiempo, que permite la programación paralela en Javascript. Sin embargo, es un complemento solo para Firefox y no he oído hablar de una hoja de ruta que incorpore esta tecnología al W3C, mucho menos ECMA.

— Demian Brecht
fuente