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
Description
I'm creating a custom runner that does more than just running the enclave. It also has other async code (network communication). At the moment the only way to use the custom runner is to call the (blocking) enclave.run method, which starts its own tokio runtime (unfortunately with an old version of tokio, see #403).
Problem or Motivation:
Because I'm using async code outside of the enclave runner I currently need two tokio runtimes:
Create a tokio runtime for the non-enclave related things in main (or with #[tokio::main])
Call spawn_blocking in my runtime
Call enclave.run in it
Which creates another tokio runtime for the enclave
Proposed solution:
Add a new async fn run_async() (or something similar), which uses an already existing runtime, does otherwise the same as enclave.run and returns a future representing the enclave running in the background. It could be almost the same as enclave.run, just not creating a runtime and returning the future instead of calling rt.block_on.
If there are restrictions of which runtime (version) this async fn can be used in: State the documentation of this function should state those.
Benefits:
No need to have two runtimes (although there may be restrictions on which version of tokio can be used on the outside, though ideally it would allow newer versions)
There can be a clear way to force stop the enclave (if that's possible), by just dropping the future or calling a function on it.
Additional context:
As stated above, ideally the enclave_runner would work with the newest tokio version, but I think this can be implemented without major impacts on other big PRs like the async usercall interface (#515)
The text was updated successfully, but these errors were encountered:
DragonDev1906
changed the title
async enclave.run function not creating a new tokio runtime
async enclave.run function that does not create a new tokio runtime
Oct 20, 2023
Description
I'm creating a custom runner that does more than just running the enclave. It also has other async code (network communication). At the moment the only way to use the custom runner is to call the (blocking) enclave.run method, which starts its own tokio runtime (unfortunately with an old version of tokio, see #403).
Problem or Motivation:
Because I'm using async code outside of the enclave runner I currently need two tokio runtimes:
#[tokio::main]
)enclave.run
in itProposed solution:
Add a new
async fn run_async()
(or something similar), which uses an already existing runtime, does otherwise the same asenclave.run
and returns a future representing the enclave running in the background. It could be almost the same asenclave.run
, just not creating a runtime and returning the future instead of callingrt.block_on
.If there are restrictions of which runtime (version) this async fn can be used in: State the documentation of this function should state those.
Benefits:
Additional context:
As stated above, ideally the enclave_runner would work with the newest tokio version, but I think this can be implemented without major impacts on other big PRs like the async usercall interface (#515)
The text was updated successfully, but these errors were encountered: