Closed DemiMarie closed 7 years ago
JerryScript has a generic approach for contexts, so you can use any model including a lua like model. It can be adopted to any environments with different computation power and memory capabilities. For example passing around a context pointer is too much work (overhead) for a 80MHz CPU, but no problem for a 1GHz CPU.
Closing due to inactivity. Please reopen if needed.
I think this is sorely needed. The current approach is very limited. I can't imagine why passing a single pointer to every JerryScript call (like Lua or other interpreters do) creates additional overhead. Is it due to register pressure?
In JerryScript we allow multiple instance models and users can add more if needed. For example JERRY_ENABLE_EXTERNAL_CONTEXT is one way to use multiple VMs.
I'm having a hard time understanding how that works. How do you switch contexts? Is this added complexity really necessary? What gains are specifically enabled by it?
OK, so after looking a bit more in detail this works by defining jerry_port_get_current_instance()
. This would introduce the problem of locking when working with two threads, or even when switching contexts by mistake while inside a native function handler. So I ask again: what is the limitation that this scheme resolves? Is passing an additional pointer in each call problematic in any platform?
@sebadoom When using multiple threads, the idea is to implement jerry_port_get_current_instance()
using the thread-local-storage API that your platform/OS/RTOS provides. This should be very straightforward. What platform/OS/... are you using?
Lua supports multiple
lua_State
instances within a process, each of which represents an entire Lua VM. Differentlua_State
s can be run on different threads simultaneously. This is much better than Jerryscript's use of global variables.This is a breaking change to the C API.