¿Por qué JavaScript no admite multihilo?


Answers

Tradicionalmente, JS estaba destinado a piezas de código cortas y de ejecución rápida. Si tenía grandes cálculos en curso, lo hizo en un servidor: la idea de una aplicación JS + HTML que se ejecutara en su navegador durante largos períodos de tiempo haciendo cosas no triviales era absurda.

Por supuesto, ahora tenemos eso. Pero los navegadores tardarán un poco en ponerse al día: la mayoría de ellos se han diseñado en torno a un modelo de subproceso único, y cambiar eso no es fácil. Google Gears minimiza 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 hilo principal (ídem). Si bien es restrictivo, este será probablemente el diseño más práctico para el futuro cercano, tanto porque simplifica el diseño del navegador como porque reduce el riesgo de permitir que los codificadores JS sin experiencia se desorienten con los hilos ...

@marcio :

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

Entonces, no les demos herramientas que sean tan fáciles de usar que cada otro sitio web que abro termine bloqueando mi navegador. Una implementación ingenua de esto te llevaría directo al territorio que causó muchos dolores de cabeza a MS durante el desarrollo de IE7: los autores de complementos jugaron rápido y suelto con el modelo de subprocesamiento, resultando en errores ocultos que se hicieron evidentes cuando los ciclos de vida de los objetos cambiaban en el hilo principal . MALO. Si está escribiendo complementos ActiveX de subprocesos múltiples para IE, supongo que viene con el territorio; no significa que deba ir más allá de eso.

Question

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




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




No conozco los motivos de esta decisión, pero sé que puede simular algunos de los beneficios de la programación de subprocesos múltiples utilizando setTimeout. Puedes dar la ilusión de múltiples procesos haciendo cosas al mismo tiempo, aunque en realidad, todo sucede en un hilo.

Solo haga que su función haga un poco de trabajo y luego llame a algo como:

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

Y cualquier otra cosa que necesite hacer (como actualizaciones de UI, imágenes animadas, etc.) sucederá cuando tenga la oportunidad.




Son las implementaciones que no admiten multi-threading. 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 se supone que Google lanzará hoy (Google Chrome) ejecuta algún código en paralelo separándolo en proceso.

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




Intel ha estado haciendo una investigación de código abierto sobre multihilo en Javascript, que fue exhibida 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 SO 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 carretera de computación para aplicaciones web




Sin embargo, puede usar la función eval para llevar concurrencia EN ALGUN GRADO

/* 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;
    }
}



¿Quiere decir por qué el lenguaje no admite multihebras o por qué los motores de JavaScript en los navegadores no son compatibles con el multihilo?

La respuesta a la primera pregunta es que JavaScript en el navegador debe ejecutarse en una caja de arena y en una máquina / forma independiente del sistema operativo, para agregar soporte de subprocesos múltiples complicaría el lenguaje y vincularía el lenguaje muy de cerca con el sistema operativo.




Links