Async application design - module or standalone?

[kpfleming]

I'm building a proof-of-concept for an application which will allow users to write Lua scripts to drive a Rust crate that my employer publishes (github.com/fastly/viceroy). The users will write test scenarios which involve building up a configuration (various objects), then launching a 'service' in the Rust code. That service will wait for incoming HTTP requests (all of this will be running in Tokio), and the script needs to be able to use an HTTP client (like lua-http) to send requests while the service is running, then receive responses back and evaluate them. Finally it would need to send some sort of signal to tell the service to shut down.

Today this is done by running things as separate processes, but this is cumbersome and it doesn't allow for the service configuration to be changed between requests without a full shutdown and restart.

I have considered two paths for doing this:

• Publish a Lua module which embeds the viceroy code and exposes all of the functionality needed to Lua; users would then require this module in their normal Lua intepreter. The module would use Tokio internally for async processing, but the interpreter would be responsible for Lua coroutines. A major downside of this approach is that we'd need to publish the module in binary form for a number of different platforms and Lua versions, which appears to be complex to do (we don't want users to have to build the module on their systems).

• Publish a complete application which uses mlua to execute a Lua script provided by the user (not as a REPL, just simple execution), after setting up the viceroy code and exposing all necessary functionality into the interpreter. This application would use Tokio and the Lua script execution would happen in a Tokio thread, allowing Tokio to manage threads for the viceroy functionality and anything else which needs them. This would be simpler to distribute as it would be a single binary built using cargo.

For the second option, I can't quite figure out whether it would be possible for the user's Lua script to make use of coroutines and similar functionality in Lua, since it would be a single chunk running in mlua's Chunk::eval or Chunk::eval_async.

[khvzak]

For the second option, I can't quite figure out whether it would be possible for the user's Lua script to make use of coroutines and similar functionality in Lua, since it would be a single chunk running in mlua's Chunk::eval or Chunk::eval_async.

For the 2nd option everything that is available in vanilla Lua are available in mlua too.
The only caveat is running async code inside user coroutines. mlua utilizes Lua coroutines for suspending/resuming code, so when Rust wants to suspend it automatically propagates through Lua to executor (Tokio) via coroutines.
If user coroutine sits in the middle, it will see the "pending" signal that has to be passed through.

However, it should possible to automatically handle this by creating a transparent wrapper around coroutine library to make any user code work fine without modifications.
Also, additional functionality can be provided for users on top of coroutines, like "select", task sets, coroutine timeouts, cancellations, etc.