hablemos del código JavaScript que tiene setInterval métodos cada 2 seg.¿La programación asíncrona significa multihilo?
También tengo un evento de animación onblur para controlarlo.
En caso de que ocurra onblur (+ animación), podría obtener la función setInterval.
Así que mi pregunta es:
¿La programación de Async significa multi-threading? (de alguna manera?)
Sé que Javascript no es un lenguaje de subprocesos múltiples.
Entonces ...?
No. Significa literalmente lo que significa-- asincrónico. Comprender la diferencia entre la programación asincrónica y la programación basada en hilos es fundamental para su éxito como programador.
En un entorno tradicional sin hilos, cuando una función debe esperar en un evento externo (como un evento de red, un evento de teclado o mouse o incluso un evento de reloj), el programa debe esperar esperar evento sucede.
En un entorno de subprocesos múltiples, muchos subprocesos individuales de programación se ejecutan al mismo tiempo. (Dependiendo de la cantidad de CPU y del soporte del sistema operativo, esto puede ser literalmente cierto, o puede ser una ilusión creada por sofisticados algoritmos de programación).Por esta razón, los entornos de subprocesos múltiples son difíciles e involucran problemas de hilos que bloquean la memoria de los demás para evitar que se sobrepasen entre sí.
En un entorno asíncrono, un hilo de proceso único se ejecuta todo el tiempo, pero puede, por razones de eventos (y esa es la clave), cambiar de una función a otra. Cuando ocurre un evento, y cuando el proceso se está ejecutando actualmente realiza un punto en el que se debe esperar a que otro evento, el núcleo Javascript a continuación, analiza la lista de eventos y entrega el siguiente, en un (formalmente) indeterminada (pero probablemente determinista) orden, al gerente de eventos.
Por esta razón, la programación asincrónica basada en eventos evita muchos de los problemas de la programación tradicional, multi-hilo, tales como problemas de contención de memoria. Todavía puede haber condiciones de carrera, ya que el orden en que se manejan los eventos no depende de usted, pero son raros y más fáciles de administrar. Por otro lado, dado que el controlador de eventos no entrega eventos hasta que la función que se está ejecutando actualmente llegue a un punto inactivo, algunas funciones pueden privar al resto de la programación. Esto sucede en Node.js, por ejemplo, cuando las personas tontamente hacen un montón de cálculos pesados en el servidor, lo mejor es meterlo en un pequeño servidor que luego el nodo "espera" para entregar la respuesta. Node.js es una gran pequeña centralita para eventos, pero cualquier cosa que tome más de 100 milisegundos debe manejarse de forma cliente/servidor.
En el entorno del navegador, los eventos DOM se tratan como puntos de evento automáticos (tienen que serlo, la modificación del DOM ofrece muchos eventos), pero incluso el Javascript mal escrito puede privar al núcleo, por lo que ambos Firefox y Chrome tiene estos "Este script ha dejado de responder" los controladores de interrupción.
¿Qué pasa con las llamadas ajax en jQuery, el código del lado del servidor hace sus cosas mientras mi navegador mantiene otras funciones ...? –
Sin embargo, esos no son hilos. Has enviado un mensaje en el código del lado del navegador al servidor. * Cuando la llamada regresa * es un evento, y se espera que su código lo recoja y haga algo con él. Mientras está esperando, eventloop va a manejar otros eventos. Cuando su evento regrese, eventloop le otorga a su devolución de llamada control total sobre el único hilo de proceso hasta que lo abandone llegando al final de la devolución de llamada, haciendo algo que provoque el progreso del evento, o creando un nuevo evento. –
una gran respuesta, gracias por explicar que de una manera razonablemente libre de jerga – Jason
Solo en el sentido de que ejecuta código al azar y corre el riesgo de condiciones de carrera. No obtendrá ningún beneficio de rendimiento al usar tiempos de espera e intervalos.
Sin embargo, WebWorkers de HTML5 no permiten multihilo real en el navegador: http://www.html5rocks.com/en/tutorials/workers/basics/
Un bucle de eventos de un solo subproceso es un buen ejemplo de ser asíncrono en un solo idioma roscado.
El concepto aquí es que adjuntas controladores de devolución de llamada doLater al eventLoop. Entonces, el eventLoop es solo un while(true) que comprueba si se cumple la marca de tiempo específica para cada controlador doLater, y si es así llama al controlador.
Para los interesados, aquí es una aplicación ingenua (y terriblemente ineficiente juguete) de un single threaded event loop in JavaScript
Esto quiere decir que, sin ningún tipo de sistema operativo el acceso planificador de hilos de la rosca única, el obligado a esperar ocupado en el doLater devoluciones de llamada.
Si tiene una llamada sleep usted podría hacer sleep hasta la próxima doLater manipulador que es más eficiente que una espera muy ocupado desde que deschedule su único hilo y dejar que el sistema operativo hacer otras cosas.
Si hay una devolución de llamada, algo tiene que llamarlo. Las unidades de ejecución son subprocesos & por lo que, sí, algún otro subproceso tiene que llamar a la devolución de llamada, ya sea directamente o mediante la cola de alguna llamada de procedimiento asincrónico al subproceso iniciador.
Es perfectamente posible que _el mismo hilo único_ llame a la devolución de llamada más tarde. – Raynos
@Raynos ¿cómo? Si un hilo llama directamente a una función, simplemente se llama 'llamada'. Si la devolución de llamada se señaliza en la secuencia en algún bucle de entrada, algo debe haber puesto en cola la devolución de llamada. Un controlador puede hacer esto directamente, pero generalmente es un hilo del kernel. –
Al tener el bucle de evento completo en vivo en el único hilo. Tenga en cuenta que el hilo no puede hacer ningún IO, solo puede hacer comunicación asíncrona consigo mismo y con cualquier cosa dentro del mismo hilo. Esto podría ser una pedantería. – Raynos
No, asincronía (ISM?) * No * requiere el paralelismo. –
debajo de las cubiertas hay hilos, pero como programador/consumidor de lenguaje no lo es. – Jason
@Jason no hay hilos debajo de la cubierta. O al menos no tiene que haberlo. – Raynos