Enable enclave exit when a TCS is blocked on I/O

[mzohreva]

This fixes issue #109

[mzohreva]

Open questions:

• Do we need to add the exit handler for other calls such as alloc/free/async_queues/insecure_time, etc?
• Is there a better way to avoid creating an extra future?

[jethrogb]

This seems complicated, I'd much rather have something where we make use of tokio's task cancellation mechanisms such as https://docs.rs/tokio/0.2.13/tokio/runtime/struct.Runtime.html#method.shutdown_timeout

[jethrogb]

Also, if this is wrapping all usercalls, couldn't it be done one level down in the stack (in usercall dispatch)?

[mzohreva]

use of tokio's task cancellation mechanisms such as https://docs.rs/tokio/0.2.13/tokio/runtime/struct.Runtime.html#method.shutdown_timeout

That would require upgrading to tokio 0.2, I'll explore that option using PR #210

couldn't it be done one level down in the stack (in usercall dispatch)?

Good idea, I'll give that a shot

[jethrogb]

Can we add some tests? Maybe they could be part of the rust-lang/rust test suite.

[mzohreva]

Just found out that the parallel future approach implemented here is not necessary. The blocking issue appears to be due to the following line in syscall_loop():

tokio::runtime::current_thread::block_on_all(select_fut.unit_error().compat()).unwrap()

The documentation for tokio::runtime::current_thread::block_on_all() says:

This first creates a new Runtime, and calls Runtime::block_on with the provided future, which blocks the current thread until the provided future completes. It then calls Runtime::run to wait for any other spawned futures to resolve.

The problematic part is the It then calls Runtime::run to wait for any other spawned futures to resolve. and that is not what we need in syscall_loop. We want to return from syscall_loop as soon as the select future returns.

I'll update this PR accordingly.

[jethrogb]

bors r+

[bors]

Build succeeded

• continuous-integration/travis-ci/push