Python Async · DacaCode

aiohttp: Peticiones HTTP Concurrentes con asyncio

Dacadev — Wed, 24 Jun 2026 00:00:00 -0500

Tabla de Contenido

En el artículo anterior cerramos con una regla clave: nunca uses APIs bloqueantes como requests dentro de una coroutine, porque bloquean el event loop. La alternativa asíncrona por excelencia para clientes HTTP es aiohttp. En este artículo la pondremos en práctica y, más importante aún, veremos cómo coordinar cientos de peticiones concurrentes con las tres APIs que asyncio ofrece para esto: gather, as_completed y wait.

Note

Aprenderás a usar aiohttp con sesiones y connection pooling, a entender el patrón async with, y a elegir entre gather, as_completed y wait según necesites resultados ordenados, procesamiento incremental o control fino sobre la cancelación.

El Patrón `async with`: Context Managers Asíncronos

Antes de tocar aiohttp debemos entender el patrón sobre el que se construye. Un context manager síncrono se define con __enter__ y __exit__ y nos permite adquirir y liberar recursos de forma segura con with. Su equivalente asíncrono usa los métodos __aenter__ y __aexit__, y se consume con async with.

La diferencia es que estos métodos son coroutines: pueden usar await internamente para adquirir o liberar el recurso sin bloquear el event loop.

class ConnectedSocket:
 def __init__(self, server_socket):
 self._connection = None
 self._server_socket = server_socket

 async def __aenter__(self): # 1
 loop = asyncio.get_event_loop()
 connection, address = await loop.sock_accept(self._server_socket)
 self._connection = connection
 return self._connection

 async def __aexit__(self, exc_type, exc_val, exc_tb): # 2
 self._connection.close()

__aenter__ se ejecuta al entrar al bloque async with y retorna el recurso (la conexión).
__aexit__ se ejecuta al salir del bloque —incluso si hay una excepción— y libera el recurso.

Esto es relevante porque, como veremos enseguida, tanto la sesión de aiohttp como cada petición que hacemos son context managers asíncronos.

sequenceDiagram
 participant C as Código (async with)
 participant CM as Context Manager
 C->>CM: await __aenter__()
 Note over CM: adquiere el recurso (sin bloquear)
 CM-->>C: retorna el recurso
 Note over C: ejecuta el bloque async with
 C->>CM: await __aexit__()
 Note over CM: libera el recurso

aiohttp: Sesiones y Connection Pooling

aiohttp, y los clientes HTTP en general, se basan en el concepto de sesión. Una ClientSession mantiene abiertas varias conexiones que luego se reutilizan entre peticiones. Esto se conoce como connection pooling y es fundamental para el rendimiento: crear una conexión TCP es costoso, así que reutilizar un pool reduce drásticamente esa sobrecarga.

import asyncio
import aiohttp
from aiohttp import ClientSession


async def fetch_status(session: ClientSession, url: str) -> int:
 async with session.get(url) as result: # 1
 return result.status


async def main():
 async with aiohttp.ClientSession() as session: # 2
 url = 'https://example.com'
 status = await fetch_status(session, url)
 print(f'Status para {url}: {status}')


asyncio.run(main())

session.get(url) es un context manager asíncrono: dentro del bloque tenemos la respuesta; al salir, la conexión vuelve al pool.
La sesión también se gestiona con async with, garantizando que todas las conexiones se cierren correctamente al terminar.

Tip

Crea una sola ClientSession y reutilízala para todas tus peticiones. Crear una sesión por petición desperdicia el connection pooling y degrada el rendimiento.

Configurando Timeouts

Por defecto aiohttp aplica un timeout de cinco minutos a cada operación. Para la mayoría de aplicaciones ese valor es demasiado alto. Podemos ajustarlo con ClientTimeout, tanto a nivel de sesión (aplica a todas las peticiones) como a nivel de petición individual.

async def fetch_status(session: ClientSession, url: str) -> int:
 diez_millis = aiohttp.ClientTimeout(total=.01) # por petición
 async with session.get(url, timeout=diez_millis) as result:
 return result.status


async def main():
 session_timeout = aiohttp.ClientTimeout(total=1, connect=.1) # por sesión
 async with aiohttp.ClientSession(timeout=session_timeout) as session:
 await fetch_status(session, 'https://example.com')

El parámetro total limita la duración completa de la operación; connect limita solo el tiempo de establecer la conexión. El timeout de la petición tiene prioridad sobre el de la sesión.

La Trampa del `await` Secuencial

Antes de lanzar muchas peticiones, hay un error sutil que conviene evitar. Supongamos que queremos ejecutar varias coroutines y recolectar resultados con una list comprehension:

❌ Secuencial
✅ Concurrente

async def main() -> None:
 delay_times = [3, 3, 3]
 # await dentro del comprehension → espera cada task antes de crear el siguiente
 [await asyncio.create_task(delay(seconds)) for seconds in delay_times]

Tarda ~9 segundos. El await fuerza a esperar cada task antes de crear el siguiente.

async def main() -> None:
 delay_times = [3, 3, 3]
 tasks = [asyncio.create_task(delay(seconds)) for seconds in delay_times] # 1
 [await task for task in tasks] # 2

Tarda ~3 segundos. Primero se crean todos los tasks, luego se esperan.

La clave está en separar la creación de los tasks (que los pone a correr en el event loop) de la espera de sus resultados. Si haces await mientras los creas, los serializas. Esta separación es precisamente lo que las siguientes APIs resuelven por nosotros.

`gather`: Recolectar Todos los Resultados

asyncio.gather recibe una secuencia de awaitables, los ejecuta concurrentemente y, cuando hacemos await sobre él, espera a que todos terminen y retorna una lista con sus resultados. Si le pasamos coroutines, las envuelve en tasks automáticamente, así que no necesitamos llamar a create_task manualmente.

async def main():
 async with aiohttp.ClientSession() as session:
 urls = ['https://example.com' for _ in range(1000)]
 requests = [fetch_status(session, url) for url in urls]
 status_codes = await asyncio.gather(*requests) # 1
 print(status_codes)

gather ejecuta las 1000 peticiones de forma concurrente y retorna sus códigos de estado.

Una garantía importante: aunque las peticiones terminen en cualquier orden, los resultados se devuelven en el mismo orden en que pasamos los awaitables. Esto hace que gather sea ideal cuando necesitas correlacionar cada resultado con su entrada.

Manejo de Excepciones en `gather`

El comportamiento ante errores se controla con el parámetro return_exceptions:

return_exceptions=False (por defecto): si cualquier awaitable lanza una excepción, esa excepción se propaga al hacer await gather. El resto de coroutines siguen ejecutándose, pero perdemos sus resultados a menos que manejemos la excepción.
return_exceptions=True: las excepciones se devuelven como parte de la lista de resultados, junto a los valores exitosos. gather nunca lanza, y nosotros decidimos cómo tratar cada error.

results = await asyncio.gather(*requests, return_exceptions=True)

exitos = [r for r in results if not isinstance(r, Exception)]
errores = [r for r in results if isinstance(r, Exception)]

Warning

gather tiene dos limitaciones: no es fácil cancelar las peticiones restantes cuando una falla, y debemos esperar a que todas terminen antes de procesar cualquier resultado. Si una petición tarda 20 s y otra 100 ms, nos bloqueamos 20 s antes de poder usar la rápida.

`as_completed`: Procesar a Medida que Terminan

Cuando queremos reaccionar a cada resultado en cuanto está disponible, asyncio.as_completed es la herramienta. Recibe una lista de awaitables y retorna un iterador de futures. Al iterar y hacer await sobre cada uno, obtenemos los resultados en el orden en que van completándose, no en el que los pasamos.

async def main():
 async with aiohttp.ClientSession() as session:
 fetchers = [
 fetch_status(session, 'https://example.com', delay=1),
 fetch_status(session, 'https://example.com', delay=1),
 fetch_status(session, 'https://example.com', delay=10),
 ]

 for finished_task in asyncio.as_completed(fetchers):
 print(await finished_task) # se imprime apenas cada uno termina

Las dos primeras peticiones se imprimen alrededor del segundo 1, sin esperar a la de 10 segundos. Esto mejora la responsividad de la aplicación. También nos da mejor control de errores: la excepción de un task se lanza justo cuando hacemos await sobre él, permitiéndonos manejarla en el momento.

as_completed admite un timeout global. Si se excede, el await sobre los futures pendientes lanza asyncio.TimeoutError, que podemos capturar:

for done_task in asyncio.as_completed(fetchers, timeout=2):
 try:
 print(await done_task)
 except asyncio.TimeoutError:
 print('¡Timeout!')

flowchart LR
 subgraph gather["gather → espera TODO"]
 G1[req 1s] --> GW[⏳ bloquea hasta el más lento]
 G2[req 1s] --> GW
 G3[req 10s] --> GW
 GW --> GR[procesa los 3 resultados]
 end
 subgraph asc["as_completed → procesa al terminar"]
 A1[req 1s] --> AR1[procesa ~1s]
 A2[req 1s] --> AR2[procesa ~1s]
 A3[req 10s] --> AR3[procesa ~10s]
 end

La desventaja de as_completed es que no es fácil saber qué tasks ya terminaron y cuáles siguen pendientes: los recibimos uno a uno por el iterador.

`wait`: Control Fino sobre la Espera

asyncio.wait es la opción más flexible. Recibe una colección de tasks y retorna dos conjuntos: done (los que terminaron, con resultado o excepción) y pending (los que siguen corriendo). A diferencia de las otras APIs, wait no lanza excepciones automáticamente ni cancela tasks por timeout; nos da el control y la responsabilidad.

Info

Es buena práctica envolver las coroutines en create_task antes de pasarlas a wait. En versiones recientes de Python, wait espera objetos Task, no coroutines crudas.

Su comportamiento se ajusta con el parámetro return_when, que acepta tres valores:

`return_when`	`wait` retorna cuando…	Uso típico
`ALL_COMPLETED` (def.)	todos los tasks terminan	equivalente a `gather`, pero con `done`/`pending`
`FIRST_EXCEPTION`	el primero falla (o todos terminan si no hay errores)	cancelar el resto al primer error
`FIRST_COMPLETED`	el primero termina (con éxito o error)	reaccionar al más rápido y cancelar el resto

Como wait nos entrega el conjunto pending, podemos cancelar explícitamente los tasks que ya no necesitamos:

async def main():
 async with aiohttp.ClientSession() as session:
 fetchers = [
 asyncio.create_task(fetch_status(session, 'https://example.com')),
 asyncio.create_task(fetch_status(session, 'https://example.com')),
 ]

 done, pending = await asyncio.wait(
 fetchers, return_when=asyncio.FIRST_COMPLETED
 )

 print(f'Terminados: {len(done)} | Pendientes: {len(pending)}')

 for task in done:
 if task.exception() is None: # 1
 print(task.result())
 else:
 print(f'Error: {task.exception()}')

 for task in pending:
 task.cancel() # 2

Como los tasks en done ya terminaron, es seguro consultar exception() y result(). Esto evita usar await con try/except.
Cancelamos manualmente lo que quedó pendiente —algo que gather no permite hacer con facilidad.

Sobre los timeouts en wait: si pasas el parámetro timeout y se agota, wait simplemente retorna done y pending hasta ese momento, sin lanzar excepción y sin cancelar los tasks pendientes. Tú decides qué hacer con ellos.

¿Cuál Debo Usar?

Las tres APIs ejecutan awaitables concurrentemente; la elección depende de cómo necesites consumir los resultados.

flowchart TD
 Start{¿Cómo necesito<br/>los resultados?} --> A[Todos juntos<br/>y ordenados]
 Start --> B[Cada uno apenas<br/>termina]
 Start --> C[Control fino:<br/>done/pending,<br/>cancelar el resto]

 A --> AG["asyncio.gather"]
 B --> AC["asyncio.as_completed"]
 C --> AW["asyncio.wait"]

 style AG fill:#3b82f6,stroke:#1e40af,color:#fff
 style AC fill:#f59e0b,stroke:#b45309,color:#fff
 style AW fill:#10b981,stroke:#065f46,color:#fff

gather → la opción más simple cuando quieres todos los resultados, en orden, y un único punto donde manejar el éxito o el error.
as_completed → cuando quieres procesar cada resultado en cuanto llega y mejorar la responsividad.
wait → cuando necesitas control fino: saber qué terminó y qué sigue pendiente, manejar errores sin excepciones implícitas y cancelar tasks manualmente.

En conclusión

aiohttp es el reemplazo asíncrono de requests; usa una ClientSession con connection pooling y reutilízala entre peticiones.
Tanto la sesión como cada petición son context managers asíncronos (async with), construidos sobre __aenter__/__aexit__.
Separa la creación de tasks de su espera: hacer await mientras los creas los serializa.
gather espera todo y devuelve resultados ordenados; controla errores con return_exceptions.
as_completed entrega resultados a medida que terminan, ideal para responsividad.
wait ofrece control fino con los conjuntos done/pending y los modos ALL_COMPLETED, FIRST_EXCEPTION y FIRST_COMPLETED.

Referencias

aiohttp — Documentación Oficial
Python asyncio.gather — Documentación Oficial
Python asyncio.as_completed — Documentación Oficial
Python asyncio.wait — Documentación Oficial
PEP 492 — Coroutines with async and await syntax
Matthew Fowler, Python Concurrency with asyncio (Manning, 2022)

Futures, Awaitables y Errores Comunes en asyncio

Dacadev — Wed, 13 May 2026 00:00:00 -0500

Tabla de Contenido

En los artículos anteriores aprendimos a crear coroutines con async/await y ejecutar tasks concurrentes. En este artículo vamos a cerrar el modelo mental: entenderemos qué son los futures, cómo se relacionan con tasks y coroutines a través de los awaitables, y veremos cómo medir el rendimiento de nuestro código asíncrono. Para cerrar, hablaremos de los dos errores más comunes al trabajar con asyncio.

Futures: Un Valor que Aún No Existe

Un future es un objeto de Python que representa un valor que esperamos obtener en algún momento, pero que todavía no tenemos. Cuando se crea, un future está en estado incompleto. Una vez que el valor llega, se establece con set_result y el future pasa a estar completado.

from asyncio import Future

my_future = Future()

print(f'¿Está completo? {my_future.done()}') # False

my_future.set_result(42)

print(f'¿Está completo? {my_future.done()}') # True
print(f'Resultado: {my_future.result()}') # 42

stateDiagram-v2
 [*] --> Incompleto: Future()
 Incompleto --> Completado: set_result(valor)
 Completado --> [*]: result() → valor

 note right of Incompleto
 done() → False
 result() → InvalidStateError
 end note

 note right of Completado
 done() → True
 result() → valor
 end note

Futures en la práctica

En la mayoría de los casos no crearás futures directamente — asyncio los gestiona internamente. Pero entender su mecánica es clave para comprender cómo funciona todo por dentro. Veamos un ejemplo donde un task establece el valor de un future después de un segundo:

from asyncio import Future
import asyncio


def hacer_peticion() -> Future:
 future = Future()
 asyncio.create_task(establecer_valor(future)) # 1
 return future


async def establecer_valor(future) -> None:
 await asyncio.sleep(1) # 2
 future.set_result(42)


async def main():
 future = hacer_peticion()
 print(f'¿Está completo? {future.done()}') # False
 valor = await future # 3
 print(f'¿Está completo? {future.done()}') # True
 print(valor) # 42


asyncio.run(main())

Crea un task que configurará el valor del future.
Espera 1 segundo antes de establecer el resultado.
await pausa main() hasta que el future reciba su valor.

sequenceDiagram
 participant M as main()
 participant F as Future
 participant T as task: establecer_valor()

 M->>F: hacer_peticion() → Future incompleto
 M->>T: create_task(establecer_valor(future))
 M->>F: await future
 Note over M: ⏸ PAUSE main()
 T->>T: await asyncio.sleep(1)
 Note over T: ⏳ 1 segundo...
 T->>F: set_result(42)
 Note over F: ✅ Completado
 F-->>M: ▶ RESUME main()
 Note over M: valor = 42

La Jerarquía de los Awaitables

Tanto las coroutines como los tasks pueden usarse con await. ¿Qué tienen en común? Ambos son awaitables — objetos que implementan el método __await__, que es lo que Python necesita para poder usar la palabra clave await sobre ellos.

La relación entre estos conceptos forma una jerarquía clara:

flowchart TD
 A["Awaitable\n(__await__)"] --> B["Coroutine"]
 A --> C["Future"]
 C --> D["Task"]

 style A fill:#8b5cf6,stroke:#5b21b6,color:#fff
 style B fill:#3b82f6,stroke:#1e40af,color:#fff
 style C fill:#f59e0b,stroke:#b45309,color:#fff
 style D fill:#10b981,stroke:#065f46,color:#fff

Awaitable es la clase base que define el protocolo __await__. Todo lo que se pueda usar con await es un awaitable.
Coroutine es una función definida con async def. Hereda de Awaitable.
Future representa un valor pendiente. También hereda de Awaitable.
Task hereda de Future. Es la combinación de un future y una coroutine: encapsula una coroutine y la ejecuta en el event loop, mientras que el future subyacente almacena el resultado cuando la coroutine termina.

Note

Un Future es qué esperamos obtener. Un Task es cómo lo obtenemos (ejecutando una coroutine). Y Awaitable es el contrato que ambos cumplen para que await funcione.

Midiendo el Tiempo de Ejecución

Cuando trabajamos con código asíncrono, medir cuánto tarda cada operación es esencial para verificar que la concurrencia realmente funciona. La mejor forma de hacerlo es con un decorador que registre el tiempo de inicio y fin de cada coroutine:

import functools
import time
from typing import Callable, Any


def async_timed():
 def wrapper(func: Callable) -> Callable:
 @functools.wraps(func)
 async def wrapped(*args, **kwargs) -> Any:
 print(f'starting {func} with args {args} {kwargs}')
 start = time.time()
 try:
 return await func(*args, **kwargs)
 finally:
 end = time.time()
 total = end - start
 print(f'finished {func} in {total:.4f} second(s)')

 return wrapped

 return wrapper

Uso en la práctica

import asyncio


@async_timed()
async def delay(delay_seconds: int) -> int:
 print(f'sleeping for {delay_seconds} second(s)')
 await asyncio.sleep(delay_seconds)
 print(f'finished sleeping for {delay_seconds} second(s)')
 return delay_seconds


@async_timed()
async def main():
 task_one = asyncio.create_task(delay(2))
 task_two = asyncio.create_task(delay(3))

 await task_one
 await task_two


asyncio.run(main())

starting <function main ...> with args () {}
starting <function delay ...> with args (2,) {}
starting <function delay ...> with args (3,) {}
finished <function delay ...> in 2.0032 second(s)
finished <function delay ...> in 3.0003 second(s)
finished <function main ...> in 3.0004 second(s)

El output confirma lo que esperamos: ambos tasks corren concurrentemente. delay(2) termina a los ~2 segundos, delay(3) a los ~3, y main() tarda ~3 segundos en total (no 5).

gantt
 title Ejecución concurrente verificada con @async_timed
 dateFormat X
 axisFormat %s

 section delay(2)
 sleep(2) :a1, 0, 2

 section delay(3)
 sleep(3) :b1, 0, 3

 section main()
 Tiempo total :c1, 0, 3

Errores Comunes en `asyncio`

Hay dos trampas frecuentes que pueden arruinar el rendimiento de una aplicación async. Ambas tienen la misma causa: bloquear el event loop.

1. Ejecutar código CPU-bound en coroutines

Cuando tenemos funciones computacionalmente costosas (cálculos matemáticos, procesamiento de datos grandes), puede parecer buena idea envolverlas en tasks para ejecutarlas concurrentemente. Pero recuerda: asyncio usa un solo hilo. El GIL garantiza que solo una instrucción de bytecode se ejecute a la vez, así que el código CPU-bound bloqueará el event loop sin importar cuántos tasks crees.

flowchart LR
 A["Código CPU-bound\nen una coroutine"] -->|"Bloquea el\nevent loop 🛑"| B["Otras tareas\nno pueden ejecutarse"]
 C["Solución"] --> D["multiprocessing\no run_in_executor()"]

 style A fill:#ef4444,stroke:#991b1b,color:#fff
 style B fill:#ef4444,stroke:#991b1b,color:#fff
 style D fill:#10b981,stroke:#065f46,color:#fff

2. Usar APIs bloqueantes

El mismo problema ocurre al usar librerías de I/O que no son asíncronas. Librerías como requests o funciones como time.sleep bloquean el hilo principal. Cuando las llamas dentro de una coroutine, bloqueas el event loop completo y ninguna otra coroutine puede ejecutarse.

❌ Bloqueante
✅ No bloqueante

No uses estas funciones dentro de coroutines

requests.get() → bloquea el event loop
time.sleep() → bloquea el event loop
Cualquier función de I/O síncrona

Usa las alternativas asíncronas

aiohttp → reemplazo async de requests
asyncio.sleep() → cede control al event loop
asyncpg → cliente async de PostgreSQL
aiofiles → lectura/escritura async de archivos

Warning

Regla general: cualquier función que realice I/O y no sea una coroutine, o que ejecute operaciones CPU costosas, debe considerarse bloqueante. Para CPU-bound, usa loop.run_in_executor() con un ProcessPoolExecutor.

En conclusión

Un Future representa un valor que aún no existe — se completa con set_result.
Un Task es un future + una coroutine: ejecuta la coroutine y almacena su resultado en el future subyacente.
Todo lo que se pueda usar con await es un Awaitable — el contrato que unifica coroutines, futures y tasks.
El decorador @async_timed permite verificar que la concurrencia funciona midiendo tiempos reales.
Los dos errores más comunes son ejecutar código CPU-bound y usar APIs bloqueantes dentro de coroutines — ambos bloquean el event loop.

Referencias

Coroutines y async/await: Tu Primer Código Asíncrono en Python

Dacadev — Tue, 12 May 2026 00:00:00 -0500

Tabla de Contenido

En los artículos anteriores construimos la base teórica: concurrencia vs paralelismo, procesos, hilos, el GIL y el event loop. Ahora es momento de escribir código. En este artículo vamos a aprender a crear coroutines, usar las palabras clave async y await, y entender exactamente qué pasa cuando pausamos y reanudamos la ejecución.

¿Qué es una Coroutine?

Una coroutine es como una función normal de Python, pero con un superpoder: puede pausar su ejecución cuando encuentra una operación que podría tardar (una petición de red, una lectura de disco, una espera). Mientras la coroutine está pausada, el event loop puede ejecutar otras tareas. Cuando la operación termina, la coroutine se “despierta” y continúa desde donde se detuvo.

Esta capacidad de pausar y reanudar es lo que le da concurrencia a nuestra aplicación.

Para trabajar con coroutines necesitamos dos palabras clave:

async def → define una coroutine.
await → pausa la coroutine hasta que la operación esperada termine.

Creando Coroutines

Crear una coroutine es casi idéntico a crear una función normal. La única diferencia es usar async def en lugar de def:

async def mi_coroutine() -> None:
 print('¡Hola mundo!')

Info

Llamar a una coroutine no la ejecuta. Solo produce un objeto coroutine. Para ejecutarla, necesitas un event loop.

# ❌ Esto NO ejecuta la coroutine
mi_coroutine() # Retorna un objeto coroutine, no imprime nada

# ✅ Esto SÍ la ejecuta
import asyncio
asyncio.run(mi_coroutine()) # Imprime: ¡Hola mundo!

Ejecutando Coroutines con `asyncio.run`

asyncio.run es el punto de entrada principal de cualquier aplicación asyncio. Veamos un ejemplo concreto:

import asyncio


async def sumar_uno(numero: int) -> int:
 return numero + 1


resultado = asyncio.run(sumar_uno(1))
print(resultado) # 2

asyncio.run hace varias cosas por nosotros:

Crea un event loop nuevo.
Ejecuta la coroutine que le pasamos hasta que se completa.
Retorna el resultado de la coroutine.
Limpia cualquier tarea pendiente y cierra el event loop.

flowchart LR
 A["asyncio.run(coroutine)"] --> B["Crea el\nEvent Loop"]
 B --> C["Ejecuta la\ncoroutine"]
 C --> D["Retorna\nel resultado"]
 D --> E["Cierra el\nEvent Loop"]

 style A fill:#3b82f6,stroke:#1e40af,color:#fff
 style C fill:#10b981,stroke:#065f46,color:#fff
 style E fill:#64748b,stroke:#334155,color:#fff

Info

asyncio.run está diseñado para ejecutarse una sola vez como entrada principal de tu aplicación. Esa única coroutine debería encargarse de lanzar todas las demás tareas.

Pausando la Ejecución con `await`

El verdadero poder de asyncio está en await. Esta palabra clave hace dos cosas:

Ejecuta la coroutine que le sigue (a diferencia de llamarla directamente, que solo crea el objeto).
Pausa la coroutine contenedora hasta que la coroutine esperada retorne un resultado.

Cuando la coroutine esperada termina, la coroutine contenedora se “despierta” y puede usar el resultado.

import asyncio


async def obtener_saludo() -> str:
 return '¡Hola desde una coroutine!'


async def main() -> None:
 saludo = await obtener_saludo() # Pausa main() hasta obtener el resultado
 print(saludo)


asyncio.run(main())

Simulando Operaciones Largas con `asyncio.sleep`

Para simular una operación de I/O de larga duración (como una petición HTTP o una consulta a base de datos), podemos usar asyncio.sleep. Esta función pausa la coroutine por el número de segundos indicado, cediendo el control al event loop.

Veamos un ejemplo más completo con una función auxiliar delay:

import asyncio


async def delay(seconds: int) -> str:
 print(f'Esperando {seconds} segundo(s)...')
 await asyncio.sleep(seconds)
 print(f'¡Espera de {seconds} segundo(s) completada!')
 return f'Esperé {seconds} segundo(s)'

La Trampa del `await` Secuencial

Ahora veamos un error muy común al empezar con asyncio. Considera este código:

import asyncio


async def sumar_uno(numero: int) -> int:
 return numero + 1


async def mensaje_hola_mundo() -> str:
 await asyncio.sleep(1)
 return '¡Hola Mundo!'


async def main() -> None:
 mensaje = await mensaje_hola_mundo() # Pausa 1 segundo
 uno_mas_uno = await sumar_uno(1) # Ejecuta después de la pausa
 print(uno_mas_uno)
 print(mensaje)


asyncio.run(main())

Cuando ejecutamos este código, pasa 1 segundo antes de que se impriman ambos resultados. Pero sumar_uno(1) es instantánea — ¿por qué espera?

Warning

await pausa toda la coroutine contenedora. No se ejecuta ningún otro código dentro de main() hasta que la expresión await retorne un valor. Como mensaje_hola_mundo() tarda 1 segundo, main() queda pausada ese segundo completo antes de siquiera llegar a sumar_uno(1).

El siguiente diagrama muestra exactamente qué pasa en cada momento:

sequenceDiagram
 participant EL as Event Loop
 participant M as main()
 participant HW as mensaje_hola_mundo()
 participant AO as sumar_uno(1)

 EL->>M: ▶ RUN main()
 Note over M: await mensaje_hola_mundo()
 M->>HW: ▶ RUN mensaje_hola_mundo()
 HW->>HW: await sleep(1)
 Note over M: ⏸ PAUSE main()
 Note over HW: ⏸ PAUSE mensaje_hola_mundo()
 Note over EL: ⏳ Pasa 1 segundo...
 EL->>HW: ▶ RESUME mensaje_hola_mundo()
 Note over HW: return '¡Hola Mundo!'
 HW-->>M: ▶ RESUME main()
 Note over M: mensaje = '¡Hola Mundo!'
 Note over M: await sumar_uno(1)
 M->>AO: ▶ RUN sumar_uno(1)
 Note over AO: return 1 + 1
 AO-->>M: ▶ RESUME main()
 Note over M: uno_mas_uno = 2
 Note over M: print() resultados

El problema visualizado

El flujo de ejecución es completamente secuencial, a pesar de usar async/await:

gantt
 title Ejecución secuencial — Sin concurrencia real
 dateFormat X
 axisFormat %s

 section main()
 await mensaje_hola_mundo() :a1, 0, 10
 await sumar_uno(1) :a2, 10, 11
 print() resultados :a3, 11, 12

Lo que queremos es que sumar_uno(1) se ejecute mientras mensaje_hola_mundo() espera su segundo de delay. Pero con await secuencial eso no es posible — cada await bloquea la coroutine hasta completarse.

¿Cómo logramos concurrencia real?

Para ejecutar múltiples coroutines de forma concurrente necesitamos herramientas como asyncio.gather o asyncio.create_task. Un adelanto rápido:

async def main() -> None:
 # ✅ Ambas coroutines corren concurrentemente
 mensaje, uno_mas_uno = await asyncio.gather(
 mensaje_hola_mundo(),
 sumar_uno(1)
 )
 print(uno_mas_uno)
 print(mensaje)

Con gather, el event loop puede ejecutar sumar_uno(1) mientras mensaje_hola_mundo() está pausada esperando su sleep. El tiempo total se mantiene en ~1 segundo en lugar de sumar ambos tiempos.

gantt
 title Ejecución concurrente — Con asyncio.gather
 dateFormat X
 axisFormat %s

 section mensaje_hola_mundo()
 await sleep(1) :a1, 0, 10

 section sumar_uno(1)
 return 1 + 1 :a2, 0, 1

 section main()
 print() resultados :a3, 10, 11

En conclusión

flowchart TD
 A["async def"] -->|"Define"| B["Coroutine"]
 B -->|"Se ejecuta con"| C["asyncio.run()"]
 B -->|"Se pausa con"| D["await"]
 D -->|"Cede control al"| E["Event Loop"]
 E -->|"Cuando I/O completa"| F["Reanuda la coroutine"]
 C -->|"Crea y gestiona"| E

 style A fill:#8b5cf6,stroke:#5b21b6,color:#fff
 style B fill:#3b82f6,stroke:#1e40af,color:#fff
 style D fill:#f59e0b,stroke:#b45309,color:#fff
 style E fill:#10b981,stroke:#065f46,color:#fff

async def define una coroutine — una función que puede pausarse.
await pausa la coroutine actual hasta que la operación esperada termine.
asyncio.run crea el event loop y ejecuta la coroutine principal.
asyncio.sleep simula operaciones de I/O de larga duración.
Usar await de forma secuencial no da concurrencia — para eso necesitamos asyncio.gather o asyncio.create_task.

Referencias

asyncio: Cómo Funcionan los Procesos, Hilos y el Event Loop

Dacadev — Mon, 11 May 2026 00:00:00 -0500

Tabla de Contenido

En el artículo anterior construimos un modelo mental sobre concurrencia, paralelismo y los tipos de multitarea. Ahora vamos a bajar un nivel: entender qué son los procesos y los hilos, por qué el GIL de Python cambia las reglas del juego, y cómo asyncio logra concurrencia con un solo hilo gracias al event loop.

Procesos e Hilos

¿Qué es un proceso?

Un proceso es una instancia de una aplicación en ejecución. Cada proceso tiene su propio espacio de memoria aislado — ningún otro proceso puede acceder a él directamente — y se ejecuta en un CPU o núcleo del sistema.

¿Qué es un hilo (thread)?

Un hilo es una unidad de ejecución más ligera que vive dentro de un proceso. A diferencia de los procesos, los hilos no tienen su propia memoria: comparten el espacio de memoria del proceso que los creó.

Todo proceso tiene al menos un hilo asociado, conocido como el hilo principal (main thread). Además, un proceso puede crear hilos adicionales, comúnmente llamados hilos de trabajo (worker threads) o hilos en segundo plano (background threads).

flowchart TB
 subgraph P1["Proceso (PID: 1234)"]
 direction TB
 M1["Memoria del proceso"]
 MT["Hilo principal\n(main thread)"]
 W1["Worker thread 1"]
 W2["Worker thread 2"]
 M1 <--> MT
 M1 <--> W1
 M1 <--> W2
 end

 style P1 fill:transparent,stroke:#64748b
 style M1 fill:#3b82f6,stroke:#1e40af,color:#fff
 style MT fill:#10b981,stroke:#065f46,color:#fff
 style W1 fill:#f59e0b,stroke:#b45309,color:#fff
 style W2 fill:#f59e0b,stroke:#b45309,color:#fff

Info

Todos los hilos dentro de un proceso comparten la misma memoria. Esto hace la comunicación entre hilos muy rápida, pero introduce el riesgo de condiciones de carrera si no se maneja con cuidado.

Verificándolo en Python

Puedes inspeccionar el proceso e hilo actual con los módulos os y threading:

import os
import threading

print(f'Proceso de Python con PID: {os.getpid()}')
total_threads = threading.active_count()
thread_name = threading.current_thread().name

print(f'Python está ejecutando {total_threads} hilo(s)')
print(f'El hilo actual es: {thread_name}')

# Output esperado
Proceso de Python con PID: 48672
Python está ejecutando 1 hilo(s)
El hilo actual es: MainThread

Por defecto, tu programa Python corre en un solo hilo (MainThread) dentro de un solo proceso.

El Global Interpreter Lock (GIL)

El GIL (Global Interpreter Lock) es uno de los temas más debatidos en la comunidad Python. En términos simples: el GIL impide que un proceso de Python ejecute más de una instrucción de bytecode a la vez, incluso si tienes múltiples hilos.

Esto significa que aunque crees varios hilos con threading, solo uno ejecuta código Python en cualquier instante.

sequenceDiagram
 participant GIL
 participant T1 as Hilo 1
 participant T2 as Hilo 2

 GIL->>T1: 🔓 GIL adquirido
 activate T1
 T1->>T1: Ejecuta bytecode
 T1->>GIL: 🔒 Libera GIL
 deactivate T1
 GIL->>T2: 🔓 GIL adquirido
 activate T2
 T2->>T2: Ejecuta bytecode
 T2->>GIL: 🔒 Libera GIL
 deactivate T2
 GIL->>T1: 🔓 GIL adquirido
 activate T1
 T1->>T1: Ejecuta bytecode
 deactivate T1

¿El GIL se libera alguna vez?

Sí. El GIL se libera durante las operaciones de I/O. Cuando un hilo hace una petición de red o una lectura de disco, libera el GIL, permitiendo que otro hilo tome el control y ejecute código Python mientras tanto.

Esto es lo que hace que threading sea útil para trabajo I/O-bound, pero ineficaz para trabajo CPU-bound.

flowchart LR
 A["Operación\nCPU-bound"] -->|"GIL retenido 🔒"| B["Solo 1 hilo\nejecuta a la vez"]
 C["Operación\nI/O-bound"] -->|"GIL liberado 🔓"| D["Otros hilos pueden\nejecutar código"]

 style A fill:#ef4444,stroke:#991b1b,color:#fff
 style B fill:#ef4444,stroke:#991b1b,color:#fff
 style C fill:#10b981,stroke:#065f46,color:#fff
 style D fill:#10b981,stroke:#065f46,color:#fff

`asyncio` y el GIL

asyncio aprovecha exactamente este comportamiento: como las operaciones de I/O liberan el GIL, puede lograr concurrencia con un solo hilo. En lugar de crear múltiples hilos, asyncio crea objetos llamados coroutines — que puedes pensar como hilos ultra-ligeros.

Note

Mientras una coroutine espera por una operación de I/O, el event loop ejecuta otras coroutines que estén listas. El resultado: concurrencia sin los problemas de sincronización del multithreading.

Concurrencia de Un Solo Hilo

La concurrencia de un solo hilo no se basa en hacer dos cosas simultáneamente (eso sería paralelismo), sino en aprovechar los tiempos de espera de las operaciones de I/O para ejecutar otras tareas. El mecanismo se apoya en tres pilares:

Sockets no bloqueantes
Delegación al SO
Event Loop

1. Sockets no bloqueantes

A diferencia de un socket estándar que detiene el programa hasta recibir una respuesta, un socket no bloqueante permite enviar una petición y devolver el control al programa inmediatamente, sin esperar el resultado.

2. Delegación al sistema operativo

Cuando el código llega a una operación de red o lectura de disco, Python le delega la espera al sistema operativo. El hilo de ejecución queda libre de inmediato.

3. El Event Loop como coordinador

Mientras el SO vigila los sockets, el hilo de Python sigue ejecutando otras tareas. Cuando el SO detecta que los datos llegaron, envía una notificación. El event loop recibe este aviso y “despierta” la tarea pausada para que procese la respuesta.

El siguiente diagrama de secuencia muestra cómo interactúan estos tres pilares:

sequenceDiagram
 participant MT as Main Thread
 participant EL as Event Loop
 participant OS as Sistema Operativo
 participant S1 as Socket 1
 participant S2 as Socket 2

 MT->>EL: Envía tareas
 EL->>EL: Ejecuta tarea 1 hasta I/O
 EL->>OS: Registra Socket 1 para monitoreo
 OS->>S1: Vigila socket
 EL->>EL: Ejecuta tarea 2 hasta I/O
 EL->>OS: Registra Socket 2 para monitoreo
 OS->>S2: Vigila socket
 S1-->>OS: Datos listos ✅
 OS-->>EL: Notifica Socket 1
 EL->>EL: Reanuda tarea 1
 S2-->>OS: Datos listos ✅
 OS-->>EL: Notifica Socket 2
 EL->>EL: Reanuda tarea 2

Cómo Funciona el Event Loop

En su forma más básica, un event loop es simplemente un bucle infinito que procesa mensajes de una cola, uno a la vez:

from collections import deque

messages = deque()

while True:
 if messages:
 message = messages.pop()
 process_message(message)

En asyncio, el event loop mantiene una cola de tasks (tareas) en lugar de mensajes simples. Cada task es un wrapper alrededor de una coroutine. Cuando una coroutine alcanza una operación de I/O, se pausa y le devuelve el control al event loop, que puede ejecutar otras tareas que no estén esperando I/O.

flowchart TD
 A["Event Loop inicia"] --> B["¿Hay tareas en la cola?"]
 B -->|Sí| C["Tomar siguiente tarea"]
 C --> D{"¿La tarea tiene\nI/O pendiente?"}
 D -->|No| E["Ejecutar hasta\nel próximo await"]
 E --> F{"¿La tarea alcanzó\nuna operación I/O?"}
 F -->|Sí| G["Pausar tarea y registrar\nsocket en el SO"]
 F -->|No| H["Tarea completada ✅\nRemover de la cola"]
 G --> B
 H --> B
 D -->|Sí, datos listos| I["Reanudar tarea"]
 I --> F
 D -->|Sí, esperando aún| B
 B -->|No| J["Esperar notificaciones\ndel SO"]
 J --> B

 style A fill:#3b82f6,stroke:#1e40af,color:#fff
 style H fill:#10b981,stroke:#065f46,color:#fff

Note

Este ciclo se repite indefinidamente hasta que todas las tareas se completan o el programa se cierra explícitamente. Si una coroutine ejecuta trabajo CPU-bound sin ceder control con await, bloqueará todo el event loop y ninguna otra tarea podrá avanzar.

En conclusión

Un proceso tiene memoria aislada; un hilo comparte memoria dentro de su proceso.
El GIL impide paralelismo real con hilos en Python, pero se libera durante operaciones de I/O.
asyncio aprovecha esta liberación del GIL para lograr concurrencia en un solo hilo mediante coroutines.
El event loop coordina las tareas: ejecuta coroutines hasta que alcanzan un await, las pausa, y reanuda otras que ya tengan datos listos.
Los sockets no bloqueantes y la delegación al SO son los mecanismos que permiten esta concurrencia sin crear múltiples hilos.

Referencias

asyncio: Los Fundamentos de la Programación Asíncrona en Python

Dacadev — Sun, 10 May 2026 00:00:00 -0500

Tabla de Contenido

Si alguna vez construiste un scraper que recorre decenas de páginas, un microservicio que atiende cientos de peticiones o un bot que consume múltiples APIs, seguro sentiste la frustración de esperar. Una petición termina, la siguiente arranca, y tu programa queda ahí sin hacer nada útil.

La librería asyncio de Python fue diseñada para resolver exactamente este problema. En este artículo vamos a construir un modelo mental sólido sobre los conceptos clave: concurrencia, paralelismo, multitarea y la diferencia entre operaciones limitadas por CPU y por E/S.

¿Qué es la programación asíncrona?

La programación asíncrona es un modelo donde las tareas de larga duración se ejecutan en segundo plano, separadas del flujo principal de tu aplicación. En lugar de bloquear todo mientras esperas una respuesta de red o una lectura de archivo, el sistema queda libre para hacer otro trabajo. Cuando la tarea termina, tu código recibe una notificación y puede procesar el resultado.

Note

asyncio — abreviación de asynchronous I/O — es la librería estándar de Python que implementa este modelo. Fue introducida en Python 3.4 y hoy es la base de frameworks modernos como FastAPI, aiohttp y Starlette.

CPU-bound vs. I/O-bound

Antes de avanzar, necesitas entender una distinción fundamental: ¿en qué está gastando tiempo tu código?

Operaciones limitadas por E/S (I/O-bound)

Tu programa pasa la mayor parte del tiempo esperando un sistema externo: la red, el disco, una base de datos. La CPU está prácticamente ociosa. Ejemplos:

Hacer peticiones HTTP.
Leer o escribir archivos en disco.
Consultar una base de datos.

Operaciones limitadas por CPU (CPU-bound)

El procesador es el cuello de botella. La CPU está activamente calculando, sin esperas externas. Ejemplos:

Calcular dígitos de pi.
Aplicar lógica de negocio sobre estructuras de datos grandes.
Procesamiento de imágenes o entrenamiento de modelos.

Ejemplo práctico

Considera este fragmento de código:

import requests

response = requests.get('https://www.example.com') # 1 - I/O-bound
items = response.headers.items()
headers = [f'{key}: {header}' for key, header in items] # 2 - CPU-bound

formatted_headers = '\n'.join(headers) # 3 - CPU-bound

with open('headers.txt', 'w') as file:
 file.write(formatted_headers) # 4 - I/O-bound

El siguiente diagrama muestra el flujo de ejecución y clasifica cada paso:

flowchart LR
 A["1. requests.get()"] -->|respuesta| B["2. List comprehension"]
 B --> C["3. join() headers"]
 C --> D["4. file.write()"]

 style A fill:#3b82f6,stroke:#1e40af,color:#fff
 style B fill:#f59e0b,stroke:#b45309,color:#fff
 style C fill:#f59e0b,stroke:#b45309,color:#fff
 style D fill:#3b82f6,stroke:#1e40af,color:#fff

🔵 Azul = I/O-bound (esperando red o disco) · 🟡 Amarillo = CPU-bound (procesando en memoria)

Info

asyncio brilla con cargas I/O-bound. Si tu cuello de botella es la CPU, necesitarás multiprocessing o concurrent.futures.

Concurrencia vs. Paralelismo

Estos dos términos se confunden constantemente, pero describen cosas distintas.

Concurrencia: alternar entre tareas

Concurrencia significa gestionar múltiples tareas en períodos de tiempo superpuestos, sin necesidad de ejecutarlas en el mismo instante. Piensa en un chef preparando dos platos: pica verduras para el plato A, lo mete al horno y empieza a trabajar en el plato B mientras el A se cocina. Solo hace una cosa a la vez, pero ambos platos avanzan.

En un sistema concurrente, una sola CPU alterna entre tareas. Mientras la tarea #1 espera por E/S, la CPU toma la tarea #2.

gantt
 title Concurrencia — Una sola CPU alternando entre tareas
 dateFormat X
 axisFormat %s

 section CPU
 App #1 :a1, 0, 2
 App #2 :a2, 2, 4
 App #1 :a3, 4, 6
 App #2 :a4, 6, 8
 App #1 :a5, 8, 10

Paralelismo: ejecución simultánea real

Paralelismo significa ejecutar múltiples tareas al mismo tiempo, lo cual requiere múltiples CPUs o núcleos.

gantt
 title Paralelismo — Múltiples CPUs ejecutando simultáneamente
 dateFormat X
 axisFormat %s

 section CPU 1
 App #1 :a1, 0, 10

 section CPU 2
 App #2 :b1, 0, 10

En palabras de Rob Pike (co-creador de Go): “La concurrencia se trata de lidiar con muchas cosas a la vez. El paralelismo se trata de hacer muchas cosas a la vez.”

Note

La concurrencia es un patrón de diseño; el paralelismo es un modelo de ejecución. asyncio logra concurrencia en un solo hilo, sin paralelismo.

Tipos de Multitarea

Existen dos enfoques principales para la multitarea, y entender la diferencia es clave para comprender dónde encaja asyncio.

Multitarea preventiva (Preemptive)

El sistema operativo decide cuándo cambiar entre tareas mediante un mecanismo llamado time slicing: divide el tiempo de CPU en intervalos pequeños y rota entre las tareas activas. Cuando el SO fuerza un cambio, se dice que está haciendo preemption.

En Python, este es el modelo que usan los módulos threading (hilos) y multiprocessing (procesos). La ventaja es que no tienes que pensar en cuándo ceder el control. La desventaja: los cambios pueden ocurrir en cualquier momento, lo que introduce condiciones de carrera y la necesidad de locks.

Multitarea cooperativa (Cooperative)

Las propias tareas deciden cuándo ceder el control. Cada tarea señala explícitamente: “Me pauso aquí, ejecuta otras tareas.” No hay intervención del SO.

Este es exactamente el modelo de asyncio. En Python, la palabra clave await es esa señal explícita:

import asyncio

async def obtener_datos():
 print("Obteniendo datos...")
 await asyncio.sleep(2) # 👈 "Me pauso aquí, ejecuta otras tareas"
 print("Datos obtenidos!")

async def procesar_datos():
 print("Procesando datos...")
 await asyncio.sleep(1) # 👈 Misma señal
 print("Datos procesados!")

async def main():
 await asyncio.gather(obtener_datos(), procesar_datos())

asyncio.run(main())

La ventaja es la predictibilidad: tú controlas exactamente dónde ocurren los cambios. El riesgo: si una tarea olvida hacer await o ejecuta una operación CPU-bound larga sin ceder control, bloquea todo el event loop.

El siguiente diagrama de secuencia ilustra cómo el event loop coordina las tareas cooperativamente:

sequenceDiagram
 participant EL as Event Loop
 participant T1 as obtener_datos()
 participant T2 as procesar_datos()

 EL->>T1: Ejecutar
 T1->>EL: await sleep(2) — cede control
 EL->>T2: Ejecutar
 T2->>EL: await sleep(1) — cede control
 EL->>T2: sleep completado — reanudar
 T2->>EL: Finalizada ✅
 EL->>T1: sleep completado — reanudar
 T1->>EL: Finalizada ✅

Comparación rápida

Preventiva
Cooperativa

Multitarea Preventiva

¿Quién cambia? El Sistema Operativo
Mecanismo: Time slicing
Herramientas en Python: threading, multiprocessing
Riesgo principal: Condiciones de carrera
Ideal para: Cargas CPU-bound o mixtas

Multitarea Cooperativa

¿Quién cambia? La propia tarea
Mecanismo: await / yield
Herramientas en Python: asyncio
Riesgo principal: Bloquear el event loop
Ideal para: Cargas I/O-bound

¿Dónde encaja `asyncio`?

Con todos estos conceptos claros, el siguiente diagrama te ayuda a decidir qué herramienta usar según tu caso:

flowchart TD
 A["¿Qué tipo de operación\nnecesitas optimizar?"] --> B{"¿Es I/O-bound?"}
 B -->|Sí| C{"¿Necesitas manejar\nmuchas conexiones?"}
 C -->|Sí| D["✅ asyncio"]
 C -->|No| E["threading o\nasyncio"]
 B -->|No| F{"¿Es CPU-bound?"}
 F -->|Sí| G{"¿Necesitas compartir\nmemoria entre tareas?"}
 G -->|Sí| H["threading\n+ locks"]
 G -->|No| I["multiprocessing"]
 F -->|Mixto| J["asyncio +\nrun_in_executor()"]

 style D fill:#10b981,stroke:#065f46,color:#fff
 style E fill:#10b981,stroke:#065f46,color:#fff
 style H fill:#f59e0b,stroke:#b45309,color:#fff
 style I fill:#3b82f6,stroke:#1e40af,color:#fff
 style J fill:#8b5cf6,stroke:#5b21b6,color:#fff

En conclusión

asyncio ofrece concurrencia, no paralelismo — todo corre en un solo hilo.
Usa multitarea cooperativa — tu código cede control explícitamente con await.
Destaca en cargas I/O-bound — peticiones de red, operaciones de archivo, consultas a bases de datos.
No es la solución para trabajo CPU-bound — para eso, combínalo con multiprocessing o usa loop.run_in_executor().

Python Async · DacaCode

aiohttp: Peticiones HTTP Concurrentes con asyncio

El Patrón async with: Context Managers Asíncronos

aiohttp: Sesiones y Connection Pooling

Configurando Timeouts

La Trampa del await Secuencial

gather: Recolectar Todos los Resultados

Manejo de Excepciones en gather

as_completed: Procesar a Medida que Terminan

wait: Control Fino sobre la Espera

¿Cuál Debo Usar?

En conclusión

Referencias

Futures, Awaitables y Errores Comunes en asyncio

Futures: Un Valor que Aún No Existe

Futures en la práctica

La Jerarquía de los Awaitables

Midiendo el Tiempo de Ejecución

Uso en la práctica

Errores Comunes en asyncio

1. Ejecutar código CPU-bound en coroutines

2. Usar APIs bloqueantes

No uses estas funciones dentro de coroutines

Usa las alternativas asíncronas

En conclusión

Referencias

Coroutines y async/await: Tu Primer Código Asíncrono en Python

¿Qué es una Coroutine?

Creando Coroutines

Ejecutando Coroutines con asyncio.run

Pausando la Ejecución con await

Simulando Operaciones Largas con asyncio.sleep

La Trampa del await Secuencial

El problema visualizado

¿Cómo logramos concurrencia real?

En conclusión

Referencias

asyncio: Cómo Funcionan los Procesos, Hilos y el Event Loop

Procesos e Hilos

¿Qué es un proceso?

¿Qué es un hilo (thread)?

Verificándolo en Python

El Global Interpreter Lock (GIL)

¿El GIL se libera alguna vez?

asyncio y el GIL

Concurrencia de Un Solo Hilo

1. Sockets no bloqueantes

2. Delegación al sistema operativo

3. El Event Loop como coordinador

Cómo Funciona el Event Loop

En conclusión

Referencias

asyncio: Los Fundamentos de la Programación Asíncrona en Python

¿Qué es la programación asíncrona?

CPU-bound vs. I/O-bound

Operaciones limitadas por E/S (I/O-bound)

Operaciones limitadas por CPU (CPU-bound)

Ejemplo práctico

Concurrencia vs. Paralelismo

Concurrencia: alternar entre tareas

Paralelismo: ejecución simultánea real

Tipos de Multitarea

Multitarea preventiva (Preemptive)

Multitarea cooperativa (Cooperative)

Comparación rápida

Multitarea Preventiva

Multitarea Cooperativa

¿Dónde encaja asyncio?

En conclusión

Referencias

El Patrón `async with`: Context Managers Asíncronos

La Trampa del `await` Secuencial

`gather`: Recolectar Todos los Resultados

Manejo de Excepciones en `gather`

`as_completed`: Procesar a Medida que Terminan

`wait`: Control Fino sobre la Espera

Errores Comunes en `asyncio`

Ejecutando Coroutines con `asyncio.run`

Pausando la Ejecución con `await`

Simulando Operaciones Largas con `asyncio.sleep`

La Trampa del `await` Secuencial

`asyncio` y el GIL

¿Dónde encaja `asyncio`?