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 馃槵.