¿Por qué JavaScript no admite subprocesos múltiples?

Question

¿Es una decisión de diseño deliberada o un problema con nuestros navegadores actuales que se solucionará en las próximas versiones?

Answer 1

JavaScript no admite subprocesos múltiples porque el intérprete de JavaScript en el navegador es un subproceso único (AFAIK).Incluso Google Chrome no permitirá que JavaScript de una sola página web se ejecute simultáneamente porque esto causaría problemas masivos de concurrencia en las páginas web existentes.Todo lo que Chrome hace es separar múltiples componentes (diferentes pestañas, complementos, etc.) en procesos separados, pero no puedo imaginar que una sola página tenga más de un hilo de JavaScript.

Sin embargo, puede utilizar, como se sugirió, setTimeout para permitir algún tipo de programación y concurrencia "falsa".Esto hace que el navegador recupere el control del hilo de renderizado e inicie el código JavaScript proporcionado a setTimeout después del número dado de milisegundos.Esto es muy útil si desea permitir que la ventana gráfica (lo que ve) se actualice mientras realiza operaciones en ella.Simplemente recorriendo, por ejemplo.Las coordenadas y actualizar un elemento en consecuencia solo le permitirán ver las posiciones inicial y final, y nada intermedio.

Usamos una biblioteca de abstracción en JavaScript que nos permite crear procesos e hilos que son todos administrados por el mismo intérprete de JavaScript.Esto nos permite ejecutar acciones de la siguiente manera:

• Proceso A, Hilo 1
• Proceso A, Hilo 2
• Proceso B, Hilo 1
• Proceso A, Hilo 3
• Proceso A, Hilo 4
• Proceso B, Hilo 2
• Pausar el proceso A
• Proceso B, Hilo 3
• Proceso B, Hilo 4
• Proceso B, Hilo 5
• Iniciar proceso A
• Proceso A, Hilo 5

Esto permite alguna forma de programación y simula paralelismo, inicio y detención de subprocesos, etc., pero no será un verdadero subproceso múltiple.No creo que alguna vez se implemente en el lenguaje en sí, ya que el verdadero subproceso múltiple solo es útil si el navegador puede ejecutar un subproceso múltiple de una sola página (o incluso más de un núcleo), y las dificultades allí son mucho mayores. que las posibilidades adicionales.

Para conocer el futuro de JavaScript, consulte esto:https://developer.mozilla.org/presentations/xtech2006/javascript/

Answer 2

Tradicionalmente, JS estaba destinado a fragmentos de código cortos y de ejecución rápida.Si tenía cálculos importantes, lo hacía en un servidor: la idea de JS+HTML aplicación que se ejecutaba en su navegador durante largos períodos de tiempo haciendo cosas no triviales era absurdo.

Por supuesto, ahora tenemos eso.Pero los navegadores tardarán un poco en ponerse al día: la mayoría de ellos han sido diseñados en torno a un modelo de subproceso único y cambiar eso no es fácil.Google Gears evita muchos problemas potenciales al requerir que la ejecución en segundo plano esté aislada: sin cambiar el DOM (ya que no es seguro para subprocesos), sin acceder a objetos creados por el subproceso principal (ídem).Si bien es restrictivo, este será probablemente el diseño más práctico para el futuro cercano, porque simplifica el diseño del navegador y porque reduce el riesgo que implica permitir que codificadores JS sin experiencia jueguen con los subprocesos...

@marcio:

¿Por qué es esa una razón para no implementar subprocesos múltiples en Javascript?Los programadores pueden hacer lo que quieran con las herramientas que tienen.

Entonces, no les demos herramientas que son tan fáciles de mal uso que todos los demás sitios web que abro terminan bloqueando mi navegador.Una implementación ingenua de esto lo llevaría directamente al territorio que causó tantos dolores de cabeza a MS durante el desarrollo de IE7:Los autores de complementos jugaron rápido y libremente con el modelo de subprocesos, lo que resultó en errores ocultos que se hicieron evidentes cuando los ciclos de vida de los objetos cambiaron en el subproceso principal.MALO.Si está escribiendo complementos ActiveX multiproceso para IE, supongo que viene con el territorio;no significa que deba ir más allá.

Answer 3

El subproceso múltiple de JavaScript (con algunas limitaciones) está aquí.Google implementó trabajadores para Gears y se están incluyendo trabajadores en HTML5.La mayoría de los navegadores ya han agregado soporte para esta función.

La seguridad de los subprocesos de los datos está garantizada porque todos los datos comunicados hacia/desde el trabajador se serializan/copian.

Para más información, lea:

http://www.whatwg.org/specs/web-workers/current-work/

http://ejohn.org/blog/web-workers/

Answer 4

No sé el motivo de esta decisión, pero sé que puedes simular algunos de los beneficios de la programación multiproceso utilizando setTimeout.Puede dar la ilusión de que hay múltiples procesos haciendo cosas al mismo tiempo, aunque en realidad todo sucede en un solo hilo.

Simplemente haga que su función trabaje un poco y luego llame a algo como:

setTimeout(function () {
    ... do the rest of the work...
}, 0);

Y cualquier otra cosa que sea necesario hacer (como actualizaciones de la interfaz de usuario, imágenes animadas, etc.) sucederá cuando tengan la oportunidad.

Answer 5

multiproceso.js envuelve Web Workers y permite un fácil subproceso múltiple en JS.Funciona en todos los navegadores nuevos, incluido iOS Safari.:)

Answer 6

¿Quiere decir por qué el lenguaje no admite subprocesos múltiples o por qué los motores JavaScript en los navegadores no admiten subprocesos múltiples?

La respuesta a la primera pregunta es que JavaScript en el navegador está diseñado para ejecutarse en una zona de pruebas y de forma independiente de la máquina/el sistema operativo, agregar soporte de subprocesos múltiples complicaría el lenguaje y vincularía demasiado el lenguaje al sistema operativo.

Answer 7

Tal como dijo Matt B, la pregunta no está muy clara.Suponiendo que está preguntando sobre la compatibilidad con subprocesos múltiples en el idioma:porque no es necesario para el 99,999% de las aplicaciones que se ejecutan actualmente en el navegador.Si realmente lo necesita, existen soluciones (como usar window.setTimeout).

En general, el subproceso múltiple es muy, muy, muy, muy, muy, muy difícil (¿dije que es difícil?) de hacerlo bien, a menos que establezca restricciones adicionales (como usar solo datos inmutables).

Answer 8

Intel ha estado realizando algunas investigaciones de código abierto sobre subprocesos múltiples en Javascript, y se presentó recientemente en GDC 2012.Aquí está el enlace para el video.El grupo de investigación utilizó OpenCL, que se centra principalmente en conjuntos de chips Intel y sistemas operativos Windows.El proyecto tiene el nombre en código RiverTrail y el código está disponible en GitHub.

Algunos enlaces más útiles:

Construyendo una autopista informática para aplicaciones web

Answer 9

Actualmente, algunos navegadores admiten subprocesos múltiples.Entonces, si lo necesita, puede usar bibliotecas específicas.Por ejemplo, vea los siguientes materiales:

• https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers(admite hilos en segundo plano);

• https://keithwhor.github.io/multithread.js/ (la biblioteca).

Answer 10

Node.js 10.5+ es compatible hilos de trabajo como característica experimental (puedes usarla con --trabajador-experimental bandera habilitada): https://nodejs.org/api/worker_threads.html

Entonces, la regla es:

• si necesitas hacer Operaciones vinculadas a E/S, luego use el mecanismo interno (también conocido como devolución de llamada/promesa/async-await)
• si necesitas hacer Operaciones vinculadas a la CPU, luego use subprocesos de trabajo.

Los subprocesos de trabajo están destinados a ser subprocesos de larga duración, lo que significa que usted genera un subproceso en segundo plano y luego se comunica con él mediante el paso de mensajes.

De lo contrario, si necesita ejecutar una carga pesada de CPU con una función anónima, puede optar por https://github.com/wilk/microjob, una pequeña biblioteca construida alrededor de subprocesos de trabajo.

Answer 11

Son las implementaciones las que no admiten subprocesos múltiples.Actualmente, Google Gears proporciona una forma de utilizar algún tipo de concurrencia mediante la ejecución de procesos externos, pero eso es todo.

El nuevo navegador que Google lanzará hoy (Google Chrome) ejecuta algún código en paralelo separándolo en el proceso.

El lenguaje central, por supuesto, puede tener el mismo soporte que, digamos, Java, pero el soporte para algo como la concurrencia de Erlang no está ni cerca del horizonte.

Answer 12

Por lo que he oído, Google Chrome tendrá javascript multiproceso, por lo que es un problema de "implementaciones actuales".

Answer 13

De acuerdo a Este artículo ya es posible implementar subprocesos de JavaScript.

Answer 14

Sin un soporte de lenguaje adecuado para la sincronización de subprocesos, ni siquiera tiene sentido probar nuevas implementaciones.Aplicaciones JS complejas existentes (p. ej.cualquier cosa que use ExtJS) probablemente fallaría inesperadamente, pero sin una synchronized palabra clave o algo similar, también sería muy difícil o incluso imposible escribir nuevos programas que se comporten correctamente.

Answer 15

Sin embargo, puede utilizar la función de evaluación para lograr la concurrencia HASTA ALGUNA MEDIDA.

/* content of the threads to be run */
var threads = [
        [
            "document.write('Foo <br/>');",
            "document.write('Foo <br/>');",
            "document.write('Foo <br/>');",
            "document.write('Foo <br/>');",
            "document.write('Foo <br/>');",
            "document.write('Foo <br/>');",
            "document.write('Foo <br/>');",
            "document.write('Foo <br/>');",
            "document.write('Foo <br/>');",
            "document.write('Foo <br/>');"
        ],
        [
            "document.write('Bar <br/>');",
            "document.write('Bar <br/>');",
            "document.write('Bar <br/>');",
            "document.write('Bar <br/>');",
            "document.write('Bar <br/>');",
            "document.write('Bar <br/>');",
            "document.write('Bar <br/>');",
            "document.write('Bar <br/>');",
            "document.write('Bar <br/>');"
        ]
    ];

window.onload = function() {
    var lines = 0, quantum = 3, max = 0;

    /* get the longer thread length */
    for(var i=0; i<threads.length; i++) {
        if(max < threads[i].length) {
            max = threads[i].length;
        }
    }

    /* execute them */
    while(lines < max) {
        for(var i=0; i<threads.length; i++) {
            for(var j = lines; j < threads[i].length && j < (lines + quantum); j++) {
                eval(threads[i][j]);
            }
        }
        lines += quantum;
    }
}

Answer 16

puedes usar jetworker, contenedor en webworkerhttps://github.com/uxitten/jetworker

Answer 17

El uso de subprocesos múltiples con javascript es claramente posible utilizando los trabajadores web que trae HTML5.

La principal diferencia entre los trabajadores web y un entorno estándar de subprocesos múltiples es que los recursos de memoria no se comparten con el subproceso principal y una referencia a un objeto no es visible de un subproceso a otro.Los hilos se comunican intercambiando mensajes, por lo que es posible implementar un algoritmo de sincronización y llamada a métodos concurrentes siguiendo un patrón de diseño basado en eventos.

Existen muchos frameworks que permiten estructurar la programación entre subprocesos, entre ellos OODK-JS, un framework OOP js que admite programación concurrente.https://github.com/GOMServices/oodk-js-oop-for-js