Interrupting a long-running tiff_read_tiles or tiff_refs call with Ctrl+C in R causes a tokio runtime panic:
thread '<unnamed>' panicked at tokio-1.x/src/runtime/scheduler/multi_thread/mod.rs:
Cannot start a runtime from within a runtime. This happens because a function (like
`block_on`) attempted to block the current thread while the thread is being used to
drive asynchronous tasks.
``
followed by extendr's catch boundary converting it to an R error:
Error in rustycogs::tiff_read_tiles(...) :
User function panicked: tiff_read_tiles
Each exported function creates its own Runtime::new() + block_on. When R's interrupt signal fires mid-flight, the cleanup path attempts to create a new runtime while the existing one is still live.
Fix: hold a single shared runtime initialised at package load time via once_cell:
ruststatic RUNTIME: once_cell::sync::Lazy<Runtime> =
once_cell::sync::Lazy::new(|| Runtime::new().unwrap());
then each function uses RUNTIME.block_on(async { ... }) rather than constructing its own.
Impact: no data corruption, extendr catches the panic gracefully and returns an R error.
Interrupting a long-running
tiff_read_tilesortiff_refscall with Ctrl+C in R causes a tokio runtime panic:Error in rustycogs::tiff_read_tiles(...) :
User function panicked: tiff_read_tiles
Each exported function creates its own
Runtime::new() + block_on. When R's interrupt signal fires mid-flight, the cleanup path attempts to create a new runtime while the existing one is still live.Fix: hold a single shared runtime initialised at package load time via once_cell:
then each function uses
RUNTIME.block_on(async { ... })rather than constructing its own.Impact: no data corruption, extendr catches the panic gracefully and returns an R error.