Saltar al contenido

El runtime que trae el framework

Tauri incluye un runtime asíncrono y lo expone por su propio módulo. Qué implica usar ese y no otro, cómo se llega a él desde cualquier sitio, y por qué importa no arrancar un segundo.

Quién arranca qué

El framework arranca un runtime asíncrono al construir la aplicación y lo expone en su propio módulo, para que uses el mismo en vez de crear otro:

Rust
use tauri::async_runtime;// lanzar una tarea que sobrevive al comandoasync_runtime::spawn(async move { … });// ejecutar algo asíncrono desde un contexto que no lo eslet r = async_runtime::block_on(async { … });// llevarse un manejador a otro sitiolet h = async_runtime::handle();

Y de ahí sale la regla del nivel: usa siempre ese módulo y no crees un runtime propio. No es purismo; son tres consecuencias concretas.

Por qué no un segundo runtime

El caso en que aparece sin querer: una biblioteca que crea su propio runtime por dentro, o un ejemplo copiado que lo construye a mano. Merece comprobarlo al añadir una dependencia asíncrona.

Llegar al runtime desde cualquier sitio

Dentro de un comando o del gancho de inicialización no hace falta nada: ya estás dentro. Fuera —en una función de biblioteca, en un manejador de eventos del sistema, en un hilo propio— el módulo del framework da acceso sin necesidad de pasar nada:

Rust
// desde un contexto síncrono cualquieratauri::async_runtime::spawn(async move { sincronizar().await; });

Y para el caso contrario —estar dentro de una función asíncrona y necesitar ejecutar algo bloqueante— la herramienta es otra, y es el nivel 23.3.

El síntoma de un runtime agotado

El runtime tiene un número limitado de hilos, y si todos están ocupados haciendo trabajo bloqueante, las tareas nuevas no se ejecutan. El síntoma es característico y desconcierta:

  • La aplicación responde: la ventana se mueve, los botones se pulsan.
  • Y ningún comando contesta. Las promesas se quedan pendientes para siempre.
  • No hay error, no hay traza, no hay pánico.

La causa es siempre la misma: código bloqueante dentro de tareas asíncronas —el aviso del nivel 15.1— repetido lo bastante como para ocupar todos los hilos. Un comando que lee un fichero grande con la API síncrona, llamado desde cinco sitios a la vez, puede hacerlo.

La solución no es subir el número de hilos, que solo retrasa el problema: es sacar el trabajo bloqueante al sitio que existe para eso, que es el nivel 23.3.