Según lo indicado por Grumdrig puede escribir código como este:
setTimeout(function() { iterateArray(array1); reportDone(1); }, 0);
setTimeout(function() { iterateArray(array2); reportDone(2); }, 0);
Sin embargo, todavía no se ejecutarán simultáneamente . He aquí una idea general de lo que sucede después de dichos tiempos de espera son llamados:
- Cualquier código después de las llamadas
setTimeout
se ejecutará inmediatamente, incluyendo la vuelve a llamar a las funciones.
- Si hay otros temporizadores en la cola que están en o después de su retraso o intervalo de tiempo, se ejecutarán uno a la vez.
- Mientras se está ejecutando cualquier temporizador, otro podría golpear su intervalo/tiempo de retardo, pero no se ejecutará hasta que el último haya finalizado.
- Algunos navegadores dan prioridad a los eventos activados por la interacción del usuario, como
onclick
y onmousemove
, en cuyo caso las funciones asociadas a esos eventos se ejecutarán a expensas de la precisión del temporizador.
- Esto continuará hasta que haya una apertura (no se han llamado anteriormente temporizadores o controladores de eventos que soliciten la ejecución). Solo entonces se ejecutarán las funciones en el código de ejemplo. Nuevamente uno a la vez, con el primero probablemente, pero sin duda ejecutando primero. Además, me atrevo a suponer que algunos navegadores pueden imponer un tiempo de retardo mínimo, lo que haría que cualquier temporizador configurado con un retraso de 0 milisegundos se ejecute incluso más tarde de lo esperado.
Obviamente, no hay una ventaja de rendimiento para ejecutar código como este. En todos los casos, hará que las cosas tarden más en completarse. Sin embargo, en casos en los que una sola tarea demora tanto en congelar el navegador (y posiblemente haga que el script "se esté tomando demasiadas" advertencias del navegador), puede ser útil dividirlo en partes de ejecución más pequeñas que se ejecutan secuencialmente después de un tiempo de retraso , dando así al navegador algo de tiempo para respirar.
Web Workers se han mencionado, y si no le preocupa la compatibilidad de IE, puede usarlos para concurrencia real. Sin embargo, existen algunas limitaciones severas en su uso impuestas por razones de seguridad.Por un lado, no pueden interactuar con el DOM de ninguna manera, lo que significa que cualquier cambio en la página todavía debe hacerse de forma síncrona. Además, todos los datos pasados a y desde los trabajadores se serializan en tránsito, lo que significa que no se pueden usar objetos JavaScript reales. Dicho esto, para el procesamiento intensivo de datos, Web Workers es probablemente una mejor solución que dividir una función en tareas con múltiples temporizadores retrasados.
Parece que le interesa el procesamiento en paralelo, no necesariamente la ejecución asincrónica? No he investigado en profundidad, pero ¿los iframes usan un hilo js por separado? No me puedo imaginar que sería divertido, pero es posible que puedas hacer algunas tareas paralelas usando funciones en iframes. – jball
iframes podría ser una técnica interesante, aunque creo que la sobrecarga del iframe sería más negativa que la que proporcionaría la programación asíncrona. – aepheus
Una idea interesante, pero creo que en la mayoría de los navegadores, un iframe usa el mismo hilo JS. De hecho, creo que en todo menos en Chrome, todas las ventanas y pestañas usan el mismo hilo JS. – Grumdrig