trabajar - ¿Por qué JavaScript no soporta multihilo?
orden de ejecucion de funciones javascript (16)
¿Quiere decir por qué el lenguaje no admite multihilo o por qué los motores de JavaScript en los navegadores no lo admiten?
La respuesta a la primera pregunta es que JavaScript en el navegador está destinado a ejecutarse en un entorno aislado y de manera independiente de la máquina / SO, agregar soporte multihebra complicaría el idioma y lo vincularía demasiado al sistema operativo.
¿Es una decisión de diseño deliberada o un problema con nuestros navegadores actuales que se rectificarán en las próximas versiones?
Actualmente algunos navegadores soportan multiprocesamiento. Entonces, si necesitas eso puedes 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 subprocesos en segundo plano);
https://keithwhor.github.io/multithread.js/ (la biblioteca).
Como dijo matt b, la pregunta no es 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 en el navegador actualmente. Si realmente lo necesita, hay soluciones alternativas (como usar window.setTimeout).
En general, el subprocesamiento múltiple es muy, muy, muy, muy, muy difícil (¿dije que es difícil?) Acertar, a menos que se pongan restricciones adicionales (como usar solo datos inmutables).
El multiproceso con javascript es claramente posible mediante el uso de trabajadores web traídos por HTML5.
La principal diferencia entre los trabajadores web y un entorno de subprocesos múltiples estándar es que los recursos de memoria no se comparten con el subproceso principal, una referencia a un objeto no es visible de un subproceso a otro. Los subprocesos se comunican mediante el intercambio de mensajes, por lo que es posible implementar un algoritmo de sincronización de llamadas simultáneas y de métodos siguiendo un patrón de diseño dirigido por eventos.
Existen muchos marcos que permiten estructurar la programación entre subprocesos, entre ellos OODK-JS, un marco OOP js que admite programación concurrente https://github.com/GOMServices/oodk-js-oop-for-js
Es la implementación que no admite 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 se supone que Google lanzará hoy (Google Chrome) ejecuta algún código en paralelo al separarlo 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á en ningún punto cerca del horizonte.
Intel ha estado realizando una investigación de código abierto sobre el multihilo en Javascript, se mostró recientemente en GDC 2012. Aquí está el enlace para el video . El grupo de investigación utilizó OpenCL, que se centra principalmente en los conjuntos de chips Intel y el sistema operativo Windows. El proyecto se llama RiverTrail y el código está disponible en GitHub
Algunos enlaces más útiles:
Construyendo una autopista de computación para aplicaciones web
JavaScript multihilo (con algunas limitaciones) está aquí. Google implementó trabajadores para Gears, y los trabajadores se están incluyendo con HTML5. La mayoría de los navegadores ya han agregado soporte para esta característica.
La seguridad del hilo de los datos está garantizada porque todos los datos comunicados al trabajador son serializados / copiados.
Para más información, lea:
JavaScript no admite subprocesos múltiples porque el intérprete de JavaScript en el navegador es un único hilo (AFAIK). Incluso Google Chrome no permitirá que el JavaScript de una sola página web se ejecute simultáneamente, ya que esto causaría problemas masivos de concurrencia en las páginas web existentes. Todo lo que hace Chrome es separar múltiples componentes (diferentes pestañas, complementos, etcétera) 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 subproceso de representación e inicie el código JavaScript suministrado para setTimeout después del número de milisegundos setTimeout . Esto es muy útil si desea permitir que la ventana gráfica (lo que vea) se actualice mientras realiza operaciones en él. Solo hacer un bucle a través de, por ejemplo, las coordenadas y actualizar un elemento en consecuencia, solo le permitirá ver las posiciones inicial y final, y nada en el medio.
Utilizamos una biblioteca de abstracción en JavaScript que nos permite crear procesos y subprocesos que son gestionados por el mismo intérprete de JavaScript. Esto nos permite ejecutar acciones de la siguiente manera:
- Proceso A, Rosca 1
- Proceso A, Rosca 2
- Proceso B, Rosca 1
- Proceso A, Rosca 3
- Proceso A, Rosca 4
- Proceso B, Rosca 2
- Pausa Proceso A
- Proceso B, Rosca 3
- Proceso B, Rosca 4
- Proceso B, Rosca 5
- Iniciar Proceso A
- Proceso A, Rosca 5
Esto permite alguna forma de programación y simula el paralelismo, el inicio y la detención de subprocesos, etc., pero no será verdadero multihilo. No creo que alguna vez se implemente en el lenguaje en sí, ya que los verdaderos subprocesos múltiples solo son útiles si el navegador puede ejecutar una única página con múltiples subprocesos (o incluso más de un núcleo), y las dificultades son mucho mayores. que las posibilidades extra.
Para el futuro de JavaScript, vea esto: https://developer.mozilla.org/presentations/xtech2006/javascript/
No conozco la razón 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 que varios procesos hacen cosas al mismo tiempo, aunque en realidad, todo sucede en un hilo.
Solo haz que tu función haga un poco de trabajo y luego llama a algo como:
setTimeout(function () {
... do the rest of the work...
}, 0);
Y cualquier otra cosa que necesite hacer (como actualizaciones de la interfaz de usuario, imágenes animadas, etc.) sucederá cuando tengan la oportunidad.
Node.js 10.5+ admite subprocesos de trabajo como característica experimental (puede usarlo con el marcador de trabajador experimental habilitado): https://nodejs.org/api/worker_threads.html
Entonces, la regla es:
- Si necesita realizar operaciones enlazadas de E / S , use el mecanismo interno (también conocido como callback / promise / async-await)
- Si necesita realizar operaciones vinculadas a la CPU , utilice subprocesos de trabajo.
Los hilos de trabajo están diseñados para ser hilos de larga duración, lo que significa que usted genera un hilo de fondo 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 ir a https://github.com/wilk/microjob , una pequeña biblioteca construida alrededor de hilos de trabajo.
Por lo que he oído, Google Chrome tendrá un javascript multihilo, por lo que es un problema de "implementaciones actuales".
Según este artículo ya es posible implementar subprocesos de JavaScript.
Sin el soporte de lenguaje adecuado para la sincronización de subprocesos, ni siquiera tiene sentido probar nuevas implementaciones. Las aplicaciones JS complejas existentes (por ejemplo, cualquier cosa que use ExtJS) probablemente se bloquearían inesperadamente, pero sin una palabra clave synchronized o algo similar, también sería muy difícil o incluso imposible escribir nuevos programas que se comporten correctamente.
Sin embargo, puede usar la función eval para llevar la concurrencia A ALGUNAS EXTENSAS
/* 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;
}
}
Tradicionalmente, JS estaba destinado a piezas de código cortas y de ejecución rápida. Si tenía cálculos importantes en curso, lo hizo en un servidor: la idea de una aplicación JS + HTML que se ejecutó en su navegador durante largos períodos de tiempo haciendo cosas no triviales era absurda.
Por supuesto, ahora tenemos eso. Sin embargo, 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 un solo hilo, 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 los 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, ya que simplifica el diseño del navegador y reduce el riesgo involucrado en permitir que los codificadores JS sin experiencia jueguen con los hilos ...
@marcio :
¿Por qué es 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 usar mal que todos los demás sitios web que abro terminan por bloquear mi navegador. Una implementación ingenua de esto lo llevaría directamente al territorio que causó a la EM tantos dolores de cabeza durante el desarrollo de IE7: los autores de complementos jugaron rápido y suelto con el modelo de subprocesamiento, 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ás escribiendo complementos de ActiveX de múltiples hilos para IE, supongo que viene con el territorio; no significa que tenga que ir más allá de eso.
Multithread.js envuelve a los trabajadores web y permite un multithreading fácil en JS. Funciona en todos los nuevos navegadores, incluyendo iOS Safari. :)