How to avoid runtime conflict?

[kwonoj]

Stack:

Panic: PanicInfo { payload: Any { .. }, message: Some(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.), location: Location { file: "/Users/ojkwon/.cargo/registry/src/index.crates.io-6f17d22bba15001f/wasmer-wasix-0.4.0/src/runtime/task_manager/mod.rs", line: 104, col: 24 }, can_unwind: true }

I'm trying to integrate existing runner logics into different implementation. The existing runtime seems having an initialized tokio runtime, which looks like causing a conflict when wasix trying to do the same thing.

Am I understanding the issue correctly? and is there way to avoid / workaround this?

[kwonoj]

Reproducible PR: vercel/next.js#50401

[Michael-F-Bryan]

You can make sure WASIX and your calling code share the same Tokio runtime by passing tokio::runtime::Handle::current() to TokioTaskManager::new() when setting up your WASI runtime.

let tasks = TokioTaskManager::new(Handle::current());
let rt = PluggableRuntime::new(Arc::new(tasks));

We've got a bunch of integration tests that run with #[tokio::test] and this is how we set the WASI runtime up to share the Tokio runtime.

wasmer/lib/wasi/tests/runners.rs

Lines 218 to 229 in c2867bb

	fn runtime() -> impl Runtime + Send + Sync {
	let tasks = TokioTaskManager::new(Handle::current());
	let mut rt = PluggableRuntime::new(Arc::new(tasks));
	let cache =
	SharedCache::default().with_fallback(FileSystemCache::new(tmp_dir().join("compiled")));
	rt.set_engine(Some(Engine::default()))
	.set_module_cache(cache);
	rt
	}

That avoids most of the "Cannot start a runtime from within a runtime" panics.

[kwonoj]

I tried suggestion, however still gettting the same unfortunately.

Currently runtime's constructed as https://github.com/swc-project/swc/blob/main/crates/swc_plugin_runner/src/wasix_runtime.rs#L23-L38, and getting same panics.

[kwonoj]

Update: for me, calling WasiFunctionEnv::cleanup causes this regardless of setting shared handle or not.