Cuando utilizas Tokio, la famosa librar铆a para c贸digo as铆ncrono en Rust, el m茅todo main de tu proyecto se convierte en as铆ncrono. Esto aplica a cualquier otra librer铆a que utilice Tokio internamente, como actix-web.

#[tokio::main]
async fn main() -> Result<()> {
    // C贸digo as铆ncrono ...
    Ok(())
}

Parece magina, pero Tokio genera un entorno completo de ejecuci贸n para gestionar el c贸digo as铆ncrono y asegurarse que tu programa finaliza sin errores. Por ello, Tokio necesita controlar el ciclo de vida la aplicaci贸n y cualquier error que cause un panic en la aplicaci贸n.

Hoy justo he corregido este problema en Wasm Workers Server. Antes, wws lanzaba el siguiente error cuando fallaba un comando:

thread '<unnamed>' panicked at 'cannot access a Thread Local Storage value during or after destruction: AccessError', /rustc/fc594f15669680fa70d255faec3ca3fb507c3405/library/std/src/thread/local.rs:422:26
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
fatal runtime error: failed to initiate panic, error 5

El problema ven铆a de c贸mo estaba gestionando los errores. Cuando un comando de la CLI fallaba, wws trataba de finalizar el programa inmediatamente llamando al m茅todo exit. Esto evitaba que Tokio pudiera finalizar el proceso de manera correcta, por lo que aplicaci贸n lanzaba un panic.

Me gustar铆a entender mejor el problema, pero a煤n necesito entender un poco m谩s c贸mo funciona Tokio. Por ahora, solo aseg煤rate de dejar a Tokio que finalize tu aplicaci贸n aunque esta falle para evitar errores de hilos 馃槵.