Problem
KompactConfig contains Rc-backed component and dispatcher builders, and KompactConfig::build() returns a boxed-local future. As a result, an async function that constructs a config and awaits build() does not produce a Send future.
This prevents runtime creation inside ordinary Tokio/Tauri thread-pool tasks such as tokio::spawn, even when the resulting KompactSystem and all application-owned inputs are otherwise Send. The limitation also propagates through library APIs that load and own an internal Kompact runtime: downstream applications cannot move the complete load future between worker threads.
A reduced shape is:
async fn create_runtime() -> Result<KompactSystem, KompactError> {
let mut config = KompactConfig::default();
// configure the runtime
config.build().await
}
// Rejected because the future returned by create_runtime is not Send.
tokio::spawn(create_runtime());The immediate workaround is to construct and configure KompactConfig entirely on a blocking worker, synchronously wait for config.build() there, and await only the outer Send blocking task. This works, but forces downstream libraries to introduce a blocking-pool boundary around system construction.
Request
Could Kompact offer a Send-compatible asynchronous system creation path? Possible forms might include making the future returned by KompactConfig::build() Send, providing a separate Send-capable builder/configuration representation, or exposing another supported API intended for creation from multi-threaded async executors.
We are currently using Kompact 0.12.
Problem
KompactConfigcontainsRc-backed component and dispatcher builders, andKompactConfig::build()returns a boxed-local future. As a result, an async function that constructs a config and awaitsbuild()does not produce aSendfuture.This prevents runtime creation inside ordinary Tokio/Tauri thread-pool tasks such as
tokio::spawn, even when the resultingKompactSystemand all application-owned inputs are otherwiseSend. The limitation also propagates through library APIs that load and own an internal Kompact runtime: downstream applications cannot move the complete load future between worker threads.A reduced shape is:
The immediate workaround is to construct and configure
KompactConfigentirely on a blocking worker, synchronously wait forconfig.build()there, and await only the outer Send blocking task. This works, but forces downstream libraries to introduce a blocking-pool boundary around system construction.Request
Could Kompact offer a Send-compatible asynchronous system creation path? Possible forms might include making the future returned by
KompactConfig::build()Send, providing a separate Send-capable builder/configuration representation, or exposing another supported API intended for creation from multi-threaded async executors.We are currently using Kompact 0.12.