runtime: Use a limited multi-threaded Tokio runtime in SGX

[kostko]

No description provided.

[codecov]

Codecov Report

Merging #5214 (bb20e69) into master (2490d26) will decrease coverage by 0.09%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #5214      +/-   ##
==========================================
- Coverage   61.41%   61.33%   -0.09%     
==========================================
  Files         512      512              
  Lines       54243    54243              
==========================================
- Hits        33316    33269      -47     
- Misses      16706    16750      +44     
- Partials     4221     4224       +3     

see 19 files with indirect coverage changes

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[peternose]

NIce, works as expected 👍

Tested on an SGX instance and can confirm, that the ephemeral secret replication deadlock problem, which occured if all key managers were restarted at the same time, is now gone.

[peternose]

Not a big fan of returning a guard, especially not in public methods.

I would maybe refactor/rename demuxer to track and purge sessions only (get_or_create, remove, reset).
update multiplexed session (close) and then do all this stuff in the dispatcher.

let frame:Frame = cbor::from_slice(&request)?;
let session = self.sessions.get_or_create_session(frame.session);
session.lock_owned().await
let message = session.process_data(frame.payload, writer).await?;
...

[kostko]

You would still need to keep the locked session as you need to also process the response, but actual RPC dispatch can only happen in the dispatcher.

[peternose]

In the future we could move this to future.rs, call it from start_runtime and pass it to dispatcher and protocol constructors.

[kostko]

Oh, that's a good idea, yeah this part needs some refactoring.