The companion Leap PR for using a single execution context per wasm interface#1484
The companion Leap PR for using a single execution context per wasm interface#1484
Conversation
| _runtime->_exec_ctx.set_module(&(_instantiated_module->get_module())); | ||
| _instantiated_module->set_context(&_runtime->_exec_ctx); | ||
| _instantiated_module->reset_max_call_depth(); | ||
| _instantiated_module->reset_max_pages(); |
There was a problem hiding this comment.
I was originally worried about the case where the apply options change between apply() calls right here.
For example reset_max_call_depth() sets the context's max call depth to initial_max_call_depth which was computed based on the options passed when the backend is created,
https://github.com/AntelopeIO/eos-vm/blob/8e1d571db99ff1eecd119c299b42886f72ef40b4/include/eosio/vm/backend.hpp#L177-L180
But the max call depth that should be configured at this point in time is what the current options protocol limits are.
But a few lines down from here,
leap/libraries/chain/webassembly/runtimes/eos-vm.cpp
Lines 141 to 147 in 295bb7c
The important part is the
initialize() call that,https://github.com/AntelopeIO/eos-vm/blob/8e1d571db99ff1eecd119c299b42886f72ef40b4/include/eosio/vm/backend.hpp#L198-L203
seems to set up the context correctly for each apply once
WASM_LIMITS2 is activated.
There was a problem hiding this comment.
Thank you for your careful analysis.
The companion PR of EOS VM AntelopeIO/eos-vm#19 for using a single execution context per wasm interface.
Resolves #1456.