¿Está garantizado que JavaScript sea un subproceso único?

Diría que sí, porque prácticamente todo el código javascript existente (al menos todo lo no trivial) se rompería si el motor javascript de un navegador lo ejecutara de forma asíncrona.

Agregue a eso el hecho de que HTML5 ya especifica Web Workers (una API explícita y estandarizada para código javascript multi-threading) introducir multi-threading en el Javascript básico sería en su mayoría inútil.

(Nota para otros comentaristas: Aunque setTimeout/setInterval, los eventos onload de HTTP-request (XHR), y eventos de interfaz de usuario (clic, enfoque, etc.) proporcionar una impresión cruda de multi-threadedness - todavía se ejecutan a lo largo de una sola línea de tiempo - uno a la vez - por lo que incluso si no sabemos su orden de ejecución de antemano, no hay necesidad de preocuparse por las condiciones externas que cambian durante la ejecución de un controlador de eventos, función temporizada o devolución de llamada XHR.)

Sí, aunque todavía puede sufrir algunos de los problemas de programación concurrente (principalmente condiciones de carrera) al usar cualquiera de las API asíncronas como setInterval y xmlhttp callbacks.

Sí, aunque Internet Explorer 9 compilará su Javascript en un subproceso separado en preparación para la ejecución en el subproceso principal. Sin embargo, esto no cambia nada para ti como programador.

JavaScript/ECMAScript está diseñado para vivir dentro de un entorno host. Es decir, JavaScript en realidad no hace nada a menos que el entorno host decida analizar y ejecutar un script dado, y proporcionar objetos de entorno que permitan que JavaScript sea realmente útil (como el DOM en los navegadores).

Creo que una determinada función o bloque de script se ejecutará línea por línea y eso está garantizado para JavaScript. Sin embargo, tal vez un entorno host podría ejecutar varios scripts en al mismo tiempo. O bien, un entorno host siempre podría proporcionar un objeto que proporciona subprocesos múltiples. setTimeout y setInterval son ejemplos, o al menos pseudo ejemplos, de un entorno host que proporciona una forma de hacer cierta concurrencia (incluso si no es exactamente concurrencia).

En realidad, una ventana padre puede comunicarse con ventanas o marcos hijos o hermanos que tienen sus propios hilos de ejecución en ejecución.

Yo diría que la especificación no impide que alguien cree un motor que ejecute javascript en múltiples subprocesos, lo que requiere que el código realice la sincronización para acceder al estado del objeto compartido.

Creo que el paradigma de no bloqueo de un solo subproceso surgió de la necesidad de ejecutar javascript en navegadores donde la interfaz de usuario nunca debería bloquearse.

Nodejs ha seguido el enfoque de los navegadores.

Rhino motor sin embargo, admite la ejecución de código js en diferentes threads . Las ejecuciones no pueden compartir el contexto, pero sí el ámbito. Para este caso específico, la documentación establece:

..."Rhino garantiza que los accesos a las propiedades de los objetos JavaScript son atómicos a través de subprocesos, pero no ofrece más garantías para scripts que se ejecutan en el mismo ámbito al mismo tiempo.Si dos scripts utilizan el mismo ámbito simultáneamente, los scripts son responsables de coordinar cualquier acceso a los variables ."

Al leer la documentación de Rhino, concluyo que puede ser posible que alguien escriba una api de javascript que también genere nuevos subprocesos de javascript, pero la api sería específica de rhino (por ejemplo, node solo puede generar un nuevo proceso).

Me imagino que incluso para un motor que soporta múltiples subprocesos en javascript debe haber compatibilidad con scripts que no consideran multi-threading o bloqueo.

Navegadores Concearning y nodejs el camino Veo que es:

• ¿Se ejecuta todo el código js en un solo subproceso? : Sí.

• ¿Puede el código js hacer que se ejecuten otros subprocesos? : Sí.

• ¿Pueden estos hilos mutar el contexto de ejecución de js?: No. Pero pueden (directa/indirectamente (?)) añadir a la cola de eventos.

Por lo tanto, en el caso de los navegadores y nodejs (y probablemente muchos otros motores) javascript no es multiproceso, pero los motores sí lo son.

No.

Voy contra la multitud aquí, pero ten paciencia conmigo. Un solo script JS está destinado a ser efectivamente un solo subproceso, pero esto no significa que no se pueda interpretar de manera diferente.

Digamos que tienes el siguiente código...

var list = [];
for (var i = 0; i < 10000; i++) {
  list[i] = i * i;
}

Esto se escribe con la expectativa de que al final del bucle, la lista debe tener 10000 entradas que son el índice cuadrado, pero la VM podría notar que cada iteración del bucle no afecta a la otra, y reinterpretar usando dos hilos.

Primer hilo

for (var i = 0; i < 5000; i++) {
  list[i] = i * i;
}

Segundo hilo

for (var i = 5000; i < 10000; i++) {
  list[i] = i * i;
}

Estoy simplificando aquí, porque los arrays JS son más complicados que los trozos tontos de memoria, pero si estos dos scripts son capaces de agregar entradas a la matriz de una manera segura para subprocesos, entonces para cuando ambos terminen de ejecutarlo tendrá el mismo resultado que la versión de subproceso único.

Si bien no estoy al tanto de que ninguna máquina virtual detecte código paralelizable como este, parece probable que pueda venir en existencia en el futuro para máquinas virtuales JIT, ya que podría ofrecer más velocidad en algunas situaciones.

Llevando este concepto más allá, es posible que el código pueda ser anotado para que la máquina virtual sepa qué convertir a código multi-threaded.

// like "use strict" this enables certain features on compatible VMs.
"use parallel";

var list = [];

// This string, which has no effect on incompatible VMs, enables threading on
// this loop.
"parallel for";
for (var i = 0; i < 10000; i++) {
  list[i] = i * i;
}

Dado que los trabajadores web están llegando a Javascript, es poco probable que esto... el sistema más feo llegará a existir, pero creo que es seguro decir que Javascript es un solo subproceso por tradición.

@Bobince está proporcionando una respuesta realmente opaca.

Tomando como referencia la respuesta de MárlyLygsson, Javascript siempre tiene un solo subproceso debido a este simple hecho: Todo en Javascript se ejecuta a lo largo de una sola línea de tiempo.

Esa es la definición estricta de un lenguaje de programación de un solo subproceso.

Bueno, Chrome es multiproceso, y creo que cada proceso se ocupa de su propio código Javascript, pero por lo que el código sabe, es "single-threaded".

No hay soporte en absoluto en Javascript para multi-threading, al menos no explícitamente, por lo que no hace una diferencia.

He probado el ejemplo de @bobince con ligeras modificaciones:

<html>
<head>
    <title>Test</title>
</head>
<body>
    <textarea id="log" rows="20" cols="40"></textarea>
    <br />
    <button id="act">Run</button>
    <script type="text/javascript">
        let l= document.getElementById('log');
        let b = document.getElementById('act');
        let s = 0;

        b.addEventListener('click', function() {
            l.value += 'click begin\n';

            s = 10;
            let s2 = s;

            alert('alert!');

            s = s + s2;

            l.value += 'click end\n';
            l.value += `result = ${s}, should be ${s2 + s2}\n`;
            l.value += '----------\n';
        });

        window.addEventListener('resize', function() {
            if (s === 10) {
                s = 5;
            }

            l.value+= 'resize\n';
        });
    </script>
</body>
</html>

Por lo tanto, cuando presione Ejecutar, cierre la ventana emergente de alerta y haga un "hilo único", debería ver algo como esto:

click begin
click end
result = 20, should be 20

Pero si intenta ejecutar esto en Opera o Firefox estable en Windows y minimizar / maximizar la ventana con alerta emergente en la pantalla, entonces habrá algo como esto:

click begin
resize
click end
result = 15, should be 20

No quiero decir, que esto es "multithreading", pero alguna pieza de código se había ejecutado en un momento equivocado conmigo no esperaba esto, y ahora tengo un estado corrupto. Y es mejor saber sobre este comportamiento.

Intente anidar dos funciones setTimeout entre sí y se comportarán multiproceso (ie; el temporizador externo no esperará a que el interno se complete antes de ejecutar su función).