You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Currently Effects in reactive_graph use any_spawner to provide a runtime. This is not suitable for environments with no globally set runtime, such as when trying to integrate reactive_graph with bevy through bevy-tokio-tasks.
Describe the solution you'd like
Versions of the Effect::new and Effect::new_sync API that allow for a callback to which you can provide custom spawn logic, for example
Effect::new_sync_with_runtime(move || {/* do something with effect */},
|task| runtime.spawn(task),);
Describe alternatives you've considered
I am not aware of an alternative way to achieve this result at present, as custom executors in any_spawner are required to be 'static, and this would enable using a runtime bound on a local lifetime (such as one provided by a bevy resource) for the execution context.
Additional context
I implemented a hacky version by forking and rewriting the new_sync function to accept a reference to a Tokio runtime directly, and it fixed the problems I was having. The callback API would be a more flexible version of this.
Is your feature request related to a problem? Please describe.
Currently Effects in
reactive_graph
useany_spawner
to provide a runtime. This is not suitable for environments with no globally set runtime, such as when trying to integratereactive_graph
withbevy
throughbevy-tokio-tasks
.Describe the solution you'd like
Versions of the
Effect::new
andEffect::new_sync
API that allow for a callback to which you can provide custom spawn logic, for exampleDescribe alternatives you've considered
I am not aware of an alternative way to achieve this result at present, as custom executors in
any_spawner
are required to be'static
, and this would enable using a runtime bound on a local lifetime (such as one provided by a bevy resource) for the execution context.Additional context
I implemented a hacky version by forking and rewriting the
new_sync
function to accept a reference to a Tokio runtime directly, and it fixed the problems I was having. The callback API would be a more flexible version of this.The text was updated successfully, but these errors were encountered: