There’s a system which let’s you specify a maximum gas limit to prevent programs from running too long, it’s in one of the pull requests and is scheduled to be added to the next version. Basically each instruction has an associated cost to run, and this cost gets accumulated while the program is running – if the accumulated amount gets higher than the limit specified the program halts.

There’s currently no way to pause a call, but I suppose that should be easy enough to implement, depending on how that’s meant to work

The frames aren’t actually being dealt with as a stack, they’re just using elixirs built in recursion on every function call. I don’t recall if we’ve tail call optimized yet but I do know that we can call wasm functions recursively millions of frames deep with no issues.

There’s no serialization at the moment, although that’s something that could also be pretty easily implemented, but I don’t think that’s a goal of Wasp – as it depends on the user to validate that the serialized state is valid and non malicious, which opens up an attack vector

board = WaspVM.HostFunction.API.get_memory(ctx, "game_mem", 0, 9) Oooo awesome!

I like the post, easy to read, follow, and understand.

As for WaspVM.HostFunction.API.get_memory/4 does that include the instruction pointer and all as well? I.E. if WASM calls ‘into’ an elixir function, can that elixir function serialize up the whole state then pick up again where it left off (assuming no other elixir functions are on the wasm stack, and probably some argument indicating whether it was just loaded or not)?

This variable is defined by the defhost macro, and is solely used as a reference that’s passed into the HostFunction API.

As for this, I’m really not a fan of magic variables, why not have the user prepend it to all defhost argument lists so it is explicitly passed in, thus:

defhost get_move_for_player(player) do

defhost draw_board do ... end

And so forth should actually be written like:

defhost get_move_for_player(vmctx, player) do

defhost draw_board(vmctx) do ... end

I always try to remember the Python tenant: Explicit is Better than Implicit

Also, does this mean you can’t call the function from outside the WaspVM interpreter? Like what would you pass in then, the PID like this?

def run_game do
  # Start a fresh VM instance
  {:ok, pid} = WaspVM.start()
  WaspVM.load_file(pid, "priv/wasm/tic_tac_toe.wasm", imports)
  {:ok, gas, result} = WaspVM.execute(pid, "play")
  WaspVM.HostFunction.API.get_memory(pid, "game_mem", 0, 9)
end

Also, the calls return the gas, but is there a way to set a limit on how much gas is allowed to be used in a call before it just exceptions out or serializes/pauses its state or so for later resumption?

Huh, this is really cool. Interesting sandbox method to let basically anyone run untrusted code. Not super performant since WASM doesn’t map to the BEAM very well but perfectly good for most untrusted code. I may make use of this.