Pues aquí estamos de nuevo. Hacía una pandemia que no escribía en este blog; debido a un buen montón de líos e imprevistos.
En esta entrada quería enumerar las situaciones más comunes, con las que es posible encontrarse, que pueden aprovechar las bondades de la programación asíncrona.
1. Dejar el hilo libre para otra solicitud.
Esta es una de las más típicas y sencillas. Simplemente se hace una espera (await) a una llamada asíncrona de algún recurso de I/O y, mientras este responde, el hilo puede ser reutilizado por el sistema para ir ejecutando otra solicitud; una vez tenemos la respuesta asíncrona, ejecutamos el resto del código. Un ejemplo típico de esto podría ser el código personalizado ejecutado por un servidor http que va procesando los request que llegan.
2. Continuar trabajando.
Esta es un pelín más complicada, puesto que hay que darse cuenta de la situación y estructurar el código acorde a esa situación.
Básicamente, si ves que puedes ejecutar algo de código que no depende de la respuesta de la llamada asíncrona, deberías lanzar la llamada asíncrona primero, sin esperar, y, seguidamente, ejecutar el código no dependiente (ergo, mientras se está procesando la llamada asíncrona; y por lo tanto ganamos tiempo).
Qué hacer con la llamada asíncrona, al final, depende de un factor:
Si seguimos necesitando ejecutar más código en la función, que sí depende de la respuesta asíncrona; debemos esperar (await) esa respuesta y ejecutar el resto del código.
Si no existe una dependencia de código en la función; podríamos usar callbacks, en vez de esperar (await), para dejar la función que estamos programando mas limpia; quitándonos de en medio la gestión de la respuesta asíncrona al delegarla en el callback.
3. Lotes de trabajos asíncronos independientes.
En este caso nos encontramos con una serie de trabajos asíncronos que no dependen unos de otros. En este caso, realizar una espera (await) de cada uno o de incluso de todos (awaitAll) es contraproducente puesto que de seguro estamos haciendo que la CPU esté parada en algunos momentos.
La estrategia a seguir aquí sería lanzar todas las tareas asíncronas sin esperas y confiar en los callbacks de cada una para procesar su respuesta.
Un ejemplo típico de esto podría ser un web scrapper que realiza solicitudes a una URL con el número de página o letra del abecedario para recorrer todo el contenido interesante de un sitio.
Esto ganaría en complejidad si tenemos tantos trabajos asíncronos que no los pudiésemos lanzar todos a la vez y tengamos que planear una estrategia de lanzarlos de 10 en 10 o incluso mejor; lanzar un nuevo a medida que otro acaba.
No hay comentarios:
Publicar un comentario